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I.  PROBLEM  SUMMARY 


A.  BACKGROUND 

The  aodern  battlefield  is  a  highly  sobile  and  fluid 
environaent  requiring  the  Tactical  Coaaander  to  be  acutely 
aware  of  terrain.  He  needs  to  "get  the  lay  of  the  land"  or 
to  gather  data  without  having  to  be  there,  and  he  aust  risk 
equipaent  and  the  lives  of  his  aen  on  this  inforaation.  A 
systea  of  paper  Baps  is  presently  in  use  which  is  adequate 
for  the  job;  however  they  are  soaetiaes  slow  and  tedious  to 
use.  Maps  are  annotated  with  pre-planned  targets,  color- 
coded  terrain  features,  coordination  lines,  routes,  check¬ 
points,  positions  and  aore.  Data  is  extracted  and 
decisions  are  aade  based  on  its  analysis.  Additionally, 
aany  of  the  preparations  by  a  coaaander  rely  on  the  aental 
pictures  of  the  terrain  built  upon  the  data  derived  froa  the 
Bap.  Potential  for  error  exists  for  all  these  operations. 
Because  a  nap  was  nisread  or  the  situation  didn’t  allow 
sufficient  tine  to  extract  the  proper  inforaation,  an  untold 
nuaber  of  aen  have  died. 

Digital  databases  which  are  being  fielded  now  by  the 
Defense  Mapping  Agency  (DMA),  for  the  first  tine  provide  a 
source  of  data  which  represent  the  inforaation  contained  in 
a  paper  nap.  With  the  availability  of  these  new  databases 
and,  in  light  of  the  state  of  current  and  future  technology, 
there  exists  the  possibility  that  naps  can  be  conputerized 
for  field  use.  The  focus  of  this  study  was  to  deteraine  if 
there  is  now  the  technical  feasibility  to  develop  a 
worthwhile  digitized  aapping  systea  for  ground  tactical 
coaaanders . 


B.  SCOPE 


1 .  Tactical  User 

Computers  in  the  field  produce  their  own  set  of 
problems.  Power  requirements ,  transportability, 
survivability  and  electronic  radiation  must  be  of  concern. 
The  capabilities  to  use  or  support  sophisticated  equipment 
vary  greatly  from  the  rear  areas  to  the  forward  edge  of  the 
battlefield.  No  one  solution  is  appropriate  to  both 
environments.  Accordingly,  to  insure  a  consistent  focus, 
this  study  has  been  limited  to  the  Marine  infantry  battalion 
or  regimental  level. 

2 .  Hardware 

A  machine  used  in  the  field  by  a  tactical  commander 
must  be  extremely  mobile.  A  Marine  Infantry  Battalion  or 
Regiment  has  finite,  and  extremely  limited,  motor 
transportation  and  power  generation  assets  available  in  its 
Table  Of  Equipment  (T/E),  and  required  movement  is  commonly 
over  very  rough  terrain.  The  requirement  for  special 
facilities  (buildings,  vehicles,  or  special  generators) 
would  make  the  support  of  a  computer  in  the  field 
implausible,  as  would  the  requirement  for  special  support 
personnel  or  significant  special  training.  The  facilities 
available  to  a  battalion  or  regimental  commander  are  only 
capable  of  supporting  a  machine  not  requiring  dedicated 
environmental  support  (i.e.  microcomputer  or  minicomputer). 

In  the  final  analysis,  there  is  a  trade-off  between 
environmental  constraints  and  system  capabilities.  There 
has  always  been  a  demand  for  equipment  with  fewer  and  fewer 
environmental  needs  as  you  approach  the  battlefield.  Modern 
warfare,  with  high  mobility  and  sophisticated  targeting  and 
intelligence-gathering  capabilities  has  in  no  way  diminished 
this.  Computing  technology  improvements  have  at  the  sane 
time  increased  the  abilities  of  smaller,  less 
environmentally  demanding  systems.  Any  technological 


solution  that  significantly  increases  the  logistical  burden, 
increases  vulnerability,  or  reduces  the  nobility  of  the 
fighting  Marine  will  be  policically  unacceptable. 
Accordingly,  the  focus  of  this  study  is  on  the  technological 
capabilities  and  constraints  of  the  aicrocoaputer .  No 
atteapt  has  been  aade  to  assess  the  political  or  econoaic 
feasibility  of  the  aicrocoaputer  or  the  feasibility  of 
ainicoaputers  or  aainfraaes. 

3 .  Data 

Probably  the  aost  critical  issue  of  this  study  was 
the  availability  of  usable  data.  The  creation  of  an 
entirely  new  database  to  support  tactical  digitized  aapping 
was  considered  to  be  iapractical.  The  DMA  has  the  aission 
of  "...producing  and  distributing  to  the  Joint  Chiefs  of 
Staff,  Unified  and  Specified  Coaaands,  Military  Departaents 
and  other  Departaent  of  Defense  users  coaplete,  credible, 
and  effective  napping,  charting  and  geodetic  products." 
("Defense  Mapping  Agency:  Digitizing  the  Future",  October 
1986)  They  currently  have  seventeen  digitized  databases  and 
are  constantly  researching  others.  Given  the  requireaent 
for  a  reliable  and  coaplete  data  source  and  the  dedication 
of  the  DMA  to  that  task,  it  was  deterained  that  only  data 
products  of  the  DMA  would  be  considered  for  use. 

Because  of  the  large  quantities  of  data  contained  on 
a  aap,  digitized  naps  fron  DMA  are  presently  available  only 
on  nine  track  tape.  These  tapes  are  not  the  ideal  aedia  for 
aicrocoaputers  and  Bust  be  converted  to  a  usable  foraat. 

The  effects  of  this  conversion  process  were  an  iaportant 
issue  but  the  exact  technical  procedure  was  considered  to  be 
outside  the  scope  of  this  study. 

C.  METHOD  OF  STUDY 

The  study  was  conducted  in  four  parts.  First,  the 
available  databases  of  digitized  napping  data  were  reviewed. 


The  appropriate  database  was  identified  and  its  strengths 
and  weaknesses  were  determined.  The  needed  data 
modifications  for  field  use  on  a  microcomputer  were  analyzed 
and  recommended.  Next,  Department  of  Defense  initiatives  in 
the  area  of  digitized  mapping  were  reviewed  to  determine 
what  advances,  relevant  to  this  study,  had  been  made.  A 
prototype  was  developed  to  expand  the  researchers' 
understanding  of  programing,  data  and  hardware  problems  and 
limitations.  The  prototype  duplicated  some  areas  previously 
addressed  by  other  programs  but  also  addressed  new  data 
concerns.  Finally,  possible  hardware  solutions,  to  problems 
uncovered  in  the  study,  were  put  forward. 
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II.  DATA 


A.  DATABASE  AVAILABILITY 

The  researchers  operated  under  the  premise  that  it  is 
not  viable  to  automate  tactical  saps  unless  existing 
databases  provide  all  required  information.  Creating  a  new 
"world-wide"  database  would  be  a  monumental  effort  and  is 
well  beyond  the  reasonable  level  of  effort  and  expense  for 
the  sole  purpose  of  the  tactical  automation  of  the  present 
mapping  system.  Furthermore,  three  forms  of  relevant  map 
data  are  available  through  the  DMA.  The  following  three 
available  databases  were  analyzed  to  determine  if  one  or 
more  of  them  were  adequate  for  the  envisioned  project. 

1 •  Digital  Terrain  Elevation  Data 

Digital  Terrain  Elevation  Data  (DTED)  has  been  used 
for  several  existing  computer  mapping  projects  (e.g. 
Terranal,  MicroDem,  and  Microfix)1.  DTED  however,  gives 
only  the  elevation  data  for  a  given  piece  of  terrain  one 
degree  of  latitude  by  one  degree  of  longitude  (1°  X  1°), 
which  in  its  complete  form  requires  two  megabytes  of  media. 
It  is  stored  as  a  binary  stream  in  1°  X  1°  cells  on  9  track 
1600  bpi  tape.  DTBD  is  very  complete  in  its  representation 
and  provides  adequate  information  for  the  elevation  or 
contour  display,  but  lacks  the  feature  data  that  is  key  to 
this  thesis.  It  would  need  to  be  converted  to  a  usable 
format  for  our  purposes. 

2 .  Digital  Features  Analysis  Data 

Digital  Features  Analysis  Data  (DFAD)  is  detailed  in 
its  feature  representation  of  terrain,  however,  it  does  not 
contain  the  necessary  elevation  data.  It,  like  the  DTED,  is 
stored  as  a  binary  stream  in  1°  X  1°  cells  on  9  track  1600 

1 .  See  Appendix  A. 
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bpi  tape,  yet  is  in  an  entirely  different  format.  This 
would  require  another  translation  utility  program  to  sake  it 
usable  on  the  target  computer.  The  DFAD  and  the  DTBD  would 
then  require  combining  into  one  foraat,  if  possible,  to  be 
of  use  in  a  tactical  aapping  systea. 

3 .  Tactical  Terrain  Analysis  Data  Base 

The  Tactical  Terrain  Analysis  Data  Base  (TTADB)  is  a 
new  storage  foraat  in  the  iapleaentation  phase  of 
developaent  by  DMA.  It  provides  an  integrated  source  of 
both  elevation  and  features  data  in  a  coaaon  foraat,  and 
will  be  fully  on  line  in  the  early  1990's.  It  is  designed 
to  conform  to  a  1:50,000  aap  presentation  format.  The 
storage  is  in  a  binary  stream  of  terrain  points  (at  12.5 
aeters  intervals)  on  9  track  1600  bpi  tape.  A  translation 
utility  prograa  has  already  been  developed  for  another 
Marine  Corps  project  (Amphibious  Objective  Area  Land 
Management  System)  by  the  Naval  Civil  Engineering  Laboratory 
(NCEL)  of  Port  Hueneae,  California.2  This  program  could  be 
converted  or  adapted  to  produce  the  exact  output  required 
for  a  tactical  digital  mapping  systea. 

4 .  Selection 

The  availability  of  these  three  databases  from  DMA, 
with  world-wide  coverage,  provides  for  a  practical  database 
source.  A  combination  of  the  DTED  and  the  DFAD  aay  be 
possible,  but  could  be  difficult  to  implement  and  aay 
introduce  unacceptable  compromises  of  accuracy  or  detail. 

The  TTADB  offers  a  consistent  data  package  without  the  need 
for  integration.  Accordingly,  the  TTADB  was  chosen  as  the 
practical  database  for  further  study. 

B.  DATABASE  DESCRIPTION 

The  Fort  Lewis-Yakiaa  Training  Area  prototype  of  the 
TTADB  was  used  as  the  data  model  for  this  study.  This  data 

2 .  See  Appendix  A . 
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is  not  in  the  final  fora  of  the  TTADB,  but  the  prototype 
■odel  should  allow  for  general  concept  illustration.  The 
Fort  Lewis-Yakiaa  Training  Area  prototype  TTADB  data  is  Bade 
up  of  199  bit  terrain  point  records  which  describe  the 
following  features:3 

Surface  Configuration 

Vegetation 

Surface  Material 

Surface  Drainage 

Transportation 

Obstacles 

The  full  proposed  TTADB  is  Bade  up  of  224  bits  per  terrain 
point  record,  and  includes  the  following  additional  feature 
descriptions: 

Aerial  Obstructions 

Special  Features/Product  Synthesis 

Text  Data 

Each  data  point  of  TTADB  is  12.5  aeters  apart.  This 
results  in  each  square  kiloaeter  being  represented  by  a  grid 
80  X  80  points,  which  is  6400  points  of  25  to  28  bytes  of  8 
bits  each.  Thus  each  square  kiloaeter  could  take  as  auch  as 
179,000  bytes.  To  represent  even  a  saall  aap  of  400  square 
kiloaeters  would  require  over  70  Megabytes  of  storage.  This 
is  a  prohibitively  large  data  base  for  both  storage  and 
aanipulation  in  a  general-purpose  aicrocoaputer  environaent 
of  1987. 

C.  DATABASE  CONVERSION 

As  previously  noted,  the  TTADB  as  provided  by  DMA  is  on 
an  inappropriate  data  aedia  for  aicro-coaputing;  9  track 
tape,  and  is  extreaely  bulky.  To  aake  the  data  useful,  it 
needs  to  be  converted  to  a  suitable  fora  and  a  reduced 


See  Appendix  B. 
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volume.  In  doing  this,  it  is  important  that  no  significant 
details  or  information  be  lost. 


1 .  Point  Reduction 

The  first  step  towards  that  goal  is  to  reduce  the 
number  of  data  points.  A  tremendous  amount  of  space  is  used 
in  the  TTADB  to  provide  a  significant  degree  of  accuracy. 
This  is  of  grave  concern  to  some  parties  who  would  use  this 
data  base.  In  fact,  on  several  occasions  Captain  M.  R. 
Reading  of  the  Defense  Happing  School  at  Fort  Belvior, 
Virginia  warned  the  researchers  of  the  accuracy  of  the  TTADB 
data  being  only  to  plus  or  minus  37.5  meters.4  "Topographic 
products,  such  as  maps,  are  produced  to  varying  degrees  of 
accuracy,  depending  on  the  source  material  availability, 
survey  control,  and  the  scale  at  which  the  product  ia 
published. "(FM  21-32,  1979,  p.  1-9)  Accuracy  of  this  degree 
is  of  primary  concern  to  engineers,  geologists,  and 
topographers;  this  is  important  to  a  much  lesser  degree  to 
tactical  ground  units.  It  was  determined  that  the  12.5 
meter  resolution  of  the  data  points  was  not  necessary  to 
support  this  project.  The  use  of  only  one  in  four  of  the 
data  points  would  suffice.  This  would  place  each  point  50 
meters  from  the  next  and  no  piece  of  terrain  would  lie  over 
35  meters  from  a  data  point.  Any  feature  that  is 
represented  by  one  of  the  ignored  data  points  should  be 
represented  in  the  nearest  point  selected  for  retention.  As 
long  as  all  appropriate  data  from  the  three  deleted  points 
can  be  transferred  to  the  remaining  point,  no  information 
should  be  lost.  The  accuracy  of  the  converted  data  base 
would  remain  largely  within  the  37.5  meters  of  accuracy 
cited  by  Captain  Reading.  The  most  significant  error  could 
be  75  meters.  That  is,  a  point  37.5  meters  off,  being  12.5 
meters  into  the  preceding  or  following  four  point  grouping. 


School) 


Telephone  conversations  between  Captain  Daly  and 
Reading  (an  instructor  at  the  Defense  Napping 
10  February  1987,  and  17  April  1987. 
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results  in  the  data  being  displaced  37.5  aeters  further,  for 
a  total  inaccuracy  of  75  aeters.  Considering  that  this  is 
the  worst  case,  the  reduction  seeas  reasonable. 

Of  more  concern  than  the  possible  inaccuracies 
generated,  is  the  possible  loss  of  feature  data.  The  three 
deleted  points  cannot  merely  be  deleted.  Any  appropriate 
data  must  be  passed  to  the  nearest  consolidated  data  point. 
Any  conflicts  ,  e.g.  one  point  has  swamp  another  has  forest 
for  a  vegetation  code,  must  be  resolved  based  on  a  sound, 
well  considered,  hierarchy  of  importance.  Fortunately  there 
are  seldom  cases  where  four  different  points  12.5  meters 
apart  each  have  different  characteristics,  each  of  which  are 
tactically  significant. 

2 .  Field  Reductions 

Having  consolidated  the  points,  the  next  issue  is 
the  amount  of  relevant  data  contained  in  the  data  base.  All 
of  the  data  in  TTADB  is  of  value  to  someone  and  there  are 
probably  cases  that  can  be  imagined  where  most  of  the  data 
could  be  used  for  some  tactical  purpose.  Realistically,  the 
majority  of  information  is  of  little  or  no  use  to  the  ground 
tactical  commander.  When  required,  much  of  the  data 
provided  could  and  would  be  confirmed  by  individuals  on  the 
scene.  Certainly,  too  much  of  the  information  is  of  a 
perishable  nature  or  seems  to  be  difficult  to  obtain.  In 
any  case  the  data  would  possibly  be  misleading  or 
unavai lab le . 

Accordingly,  the  number  of  data  fields  was  reduced 
to  more  realistically  reflect  the  significant  needs  of  the 
tactical  users.  While  the  decisions  made  are  arguable,  they 
are  at  least  logical.  An  in-depth  review  of  the  data 
required  is  beyond  the  scope  of  this  study.  Decisions  were 
made  as  to  what  to  cut  and  what  to  retain  on  the  basis  of 
what  an  individual  expects  to  see  on  a  paper  map  and  what 
information  would  and  should  be  relied  on  after  the  data  is 


aged.  Extras  and  tiae  sensitive  data  were  deleted.  These 
reductions  resulted  in  a  lore  streamlined,  concise,  and 
understandable  data  base.5 

3 .  Field  Consolidations 

To  reduce  the  data  fields  requirements  even  more, 
data  fields  which  provided  qualifiers  were  added  to  the 
fields  which  they  qualified.  This  adds  an  additional 
requirement  that  the  data  fields  be  integrated  with 
prioritization  of  which  data  is  represented  in  cases  of 
conflict.  In  most  cases  the  relationships  lend  themselves 
to  easy  prioritization.  The  surface  drainage  data  was 
appended  to  the  vegetation  overlay.  The  highways  and  roads 
data  fields  were  added  to  the  transportation  overlay  as  was 
the  transportation  qualifier  field.  This  final  cut  reduces 
each  point's  storage  requirement  to  less  than  four  bytes. 

The  400  square  kilometer  map  which  was  impossibly  large  in 
the  original  form,  can  now  be  stored  on  two  standard  360  KB, 
5  1/4  inch  diskettes  with  room  to  spare. 

4 •  Prototype  Format 

With  the  data  minimized,  consideration  has  to  be 
given  to  a  usable  format.  The  first  decision  was  to  change 
to  a  byte  ASCII  format,  versus  a  binary  bit  format.  This 
approach  offers  three  advantages.  First,  each  edited  byte 
field  has  the  potential  for  future  expansion.  That  is, 
representing  the  vegetation  currently  requires  only  5  bits 
which  allows  only  32  bit  combinations.  The  use  of  a  full 
byte  allows  256  combinations.  Second,  bytes  and  ASCII 
characters  can  be  dealt  with  more  straight  forwardly  in  the 
DOS  environment.  Finally,  and  most  importantly,  the  ASCII 
byte  format  can  be  read  easily  by  humans.  Information  can 
be  extracted  from  the  data  by  looking  at  it,  whereas  binary 
is  all  but  incomprehensible. 
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Another  concern  is  for  expansion  froa  the  ainiaua 
data  base  to  include  fields  discarded  in  this  review,  but 
required  by  others.  Also  there  is  a  need  to  include  space 
for  locally  applied  inforaation  (ie.  targets,  unit 
locations,  bunkers,  etc.).  To  accoaaodate  this  concern,  two 
blank  byte  fields  were  added.  The  final  prototype  data 
foraat  is  as  follows: 

TABLE  1.  TDMS  PROTOTYPE  DATA  FORMAT 


Bvte 

Purpose 

Reaarks 

1-4 

Elevation 

+9999  to 

-999  aeters 

5 

Transportation 

overlay 

Coabines 

Highways 

Type,  Qualifier  and 
/  Roads  Type  fields 

6 

Vegetation 

overlay 

Coabines 

Surface 

Vegetation  and 

Drainage  Type  fields 

7-8 

Expansion/ local 

use 

Not  used 

The  prototype  foraat  provides  a  reasonable  basis  for 
evaluation.  While  it  does  not  include  all  data  of  the 
original  TTADB ,  it  includes  its  significant  detail  and  data 
fields.  The  byte  versus  bit  foraat  and  the  addition  of  two 
bytes  allows  for  aoderate  expansion.  If  aore  detail  is 
required,  going  to  a  bit  foraat  within  the  8  byte  size  could 
accoaaodate  a  60k  increase.  With  8  bytes  a  400  square 
kiloaeter  area  can  be  stored  on  one  3  1/2  inch  1.44  aegabyte 
diskette.  A  20  aegabyte  hard  disk  would  store  well  over 
5000  square  kiloaeters. 


Table  number  2  illustrates  the  data  size 
relationships  for  the  above  described  reduction  efforts: 


TABLE  2.  TOMS  DATA  STORAGE  REQUIREMENTS 


Points 
per  so  k 

Size 

Max  total 
bvtes  ~ 

400so  k 
bytes 

Initial 

80x80=6400 

25  to  28  bytes 

179,200 

71,680,000 

AFTER  Reducing 
20x20=400 

Points 

25  to  28  bytes 

11,200 

4,480,000 

AFTER  Reducing 
20x20=400 

Fields 

33  bits/5  bytes 

2000 

800,000 

AFTER  Consolidating  Fields 
20x20=400  25  bits/4  bytes 

1600 

640,000 

Prototype  Format 

20x20=400  8  bytes 

3400 

1,360,000 

D.  TBST  DATA  GENERATION 

The  data  for  the  thesis  was  manually  generated  in  the 
prototype  format  to  emulate  TTADB  data  after  reduction  and 
reformatting  as  discussed  above.  Actual  data  was  not 
utilized  for  three  reasons.  First,  the  creation  of  a 
mainframe  conversion  program  is  outside  the  scope  and 
resource  limitations  of  this  study.  Second,  the  relatively 
small  amount  of  data  required  (8  square  kilometers)  does  not 
justify  the  effort.  Lastly,  the  creation  and  use  of  actual 
data  would  not  provide  any  additional  insight  and  would  be 
disappointingly  lacking  in  mixes  of  features  desired  to 
adequately  test  the  prototype  mapping  display.  Therefore, 
data  was  designed  in  the  TTADB  format,  with  very  dense 
terrain  features  to  test  the  display  and  prototype  program. 

|  E.  DATA  CONCERNS 

Having  reviewed  databases  and  created  test  data,  several 
broad  general  concerns,  outside  the  scope  of  study, 
developed.  The  TTADB  does  not  contain  information  for 
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labels  such  as  town  naies  or  road  numbers.  The  proposed 
"text  data"  fields  aay  include  soae  information,  but  without 
greatly  increasing  the  record  size  little  inforaation  could 
be  passed  through  that  aeans.  The  next  concern  is  that  of 
users  perception  of  data  reliability.  The  TTADB  has  not  had 
years  of  field  use  nor  has  it  even  been  implemented. 
Conventional  Baps  are  trusted  because  they  are  a  known 
resource  and  can  be  judged  by  their  overall  appearance  of 
quality.  Digitized  aaps  are  a  new,  untested  eleaent  and, 
since  they  reside  as  electronic  bits  and  bytes,  cannot  be 
touched  and  studied.  This  aakes  it  difficult  for  the  user 
to  develop  confidence  in  the  product  regardless  of  how  good 
it  aay  be.  Another  concern  is  for  the  sharing  of 
inforaation  between  data  points.  Bach  point  is  concerned 
only  with  the  data  at  that  location.  Often  features  only 
gain  significance  as  a  group  of  points.  It  is  difficult  to 
envision  that  the  coaplete  iaage  of  a  feature,  taken  apart 
piece  by  piece,  can  always  be  reassembled  without 
distortion.  These  concerns  are  outside  of  the  scope  of  this 
study  and  are  offered  for  consideration  only. 


III.  RBLATBD  DEPARTMENT  OF  DEFENSE  PROGRAMS 

All  programs  of  a  similar  nature  were  studied  to 
determine  what  lessons  could  be  learned.  The  following 
programs  were  discovered  to  use  digitized  data  on  a  computer 
system  for  terrain  analysis. 

A.  PROGRAMS 

1 •  AOALMS  (Amphibious  Objective  Area  Land  Management 

Sygtem) 

The  AOALMS  is  a  prototype  that  was  designed  by  the 
Naval  Civil  Engineering  Laboratory  for  the  Marine  Corps,  and 
written  in  Janus  Ada,  to  assist  in  rapid  planning  of 
horizontal  construction  projects  before  arrival  in  the 
Amphibious  Objective  Area  (AOA).  It  is  for  use  by  the 
Landing  Force  Commander  and  the  Engineer  Support  Battalion 
for  the  planning  and  construction  of  facilities  worldwide. 

The  system  consists  of  an  MS-DOS  microcomputer  and 
software  programs  that  aid  in:  (1)  examining  site  conditions 
and  identifying  promising  locations  for  construction,  (2) 
designing  the  facilities  and  calculating  earthwork 
requirements,  (3)  determining  the  numbers  and  types  of 
construction  equipment  needed  to  meet  completion  schedules, 
and  (4)  in  scheduling  the  construction  effort  to  ensure 
optimum  usage  of  construction  equipment.  The  primary 
function  being  considered  (and  the  only  one  presently 
addressed  by  the  program)  is  construction  of  expeditionary 
airfields.  Funding  for  this  project  was  discontinued  before 
development  could  be  completed.6 
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VJSTA  (VISION.  INTERVISIBILITY.  SURROGATE  TB A  V P  t. , 
TERRAIN  ANALYSIS) 

VISTA  is  an  interactive  graphic  terrain  analysis 
program  developed  by  the  Armored  Systems  Division,  US  Army 
TRADOC  Systems  Analysis  Activity  (TRASANA),  for  detailed 
study  of  terrain.  It  was  written  in  Fortran  77  and  is 
implemented  on  Digital’s  VAX  11-780  computer  system  using 
high  resolution,  color,  graphics  terminals  to  display  and 
analyze  terrain  data  in  a  variety  of  ways.  The  supporting 
data  base  was  constructed  specifically  for  the  project  based 
on  DMA’s  TTADD,  and  consists  of  elevations,  surface 
features,  roads,  rivers,  hydrography,  and  obstacles.  VISTA 
currently  operates  on  a  12x12  kilometer  area  at  100- meter 
resolution.  The  terrain  data  can  be  displayed  in  map  form 
as  shaded  relief,  color  contours,  or  regular  contours. 

Three  modes  are  used  to  examine  the  map  display:  Line-Of- 
Sight  (LOS),  Perspective  Viewing,  and  Surrogate  Travel.  LOS 
displays  the  view  as  observed  from  different  points  on  the 
map.  Perspective  Viewing  allows  the  user  to  position  an 
observer  at  any  point  on  or  outside  the  terrain  to  obtain  a 
[  3-D  view  of  the  terrain  and  surrounding  features  as  they 

would  appear  from  that  point.  Surrogate  Travel  presents  an 
animated  3-D  perspective  view  of  travel  along  defined 
surface  or  aerial  routes  within  the  displayed  terrain  area. 
The  visual  representation  of  built-up  areas  and  vehicular 
movement  are  the  strengths  of  this  program.7 
3-  MICRODKM 

MicroDEM  was  developed  at  the  U.  S.  Military  Academy 
to  support  the  Army’s  needs  for  computer  assisted  terrain 
analysis.  It  manipulates  large  digital  terrain  models, 
developed  from  DMA's  Digital  Terrain  Elevation  Data  base,  to 
produce;  (1)  color  tinted  contour  maps,  (2)  slope  maps,  (3) 
masked  topographic  profiles,  and  (4)  3D  oblique  views  of 
terrain.  The  program  will  run  on  MS-DOS  computers  equipped 
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with  a  CGA  Monitor,  at  least  one  disk  drive  and  256  Kbytes 
of  aeaory.  It  was  written  in  Borland  International’s  Turbo 
Pascal  (ver.  3.0,  1985).  The  MicroDBM  program  aost  closely 
Matched  the  concepts  and  goals  of  this  study,  therefore  is 
was  analyzed  in  soae  depth,  as  described  below.8 

B.  MICRODEM/TERRANAL 

1 .  Background 

TERRANAL  is  a  prograa  developed  by  the  Coaputer 
Graphics  Laboratory  of  the  United  States  Military  Acadeay. 
The  originator  of  the  project  was  then  Captain  Peter  L. 
Guth,  an  instructor  in  the  Geography  departaent.  He  was 
assisted  by  Captain  Eugene  K.  Ressler  and  others  before  he 
resigned  from  the  Aray  to  take  a  position  in  the  Geology 
Departaent  at  University  of  Nevada  at  Las  Vegas.  Captain 
Ressler  took  over  cognizance  of  the  project,  but  Major  Guth 
(USAR)  continues  to  work  on  the  prograa  to  "civilianize"  it 
It  was  later  released  as  MicroDBM,  which  had  a  few 
refineaents  over  the  original. 

TERRANAL  was  conceived  and  designed  to:  (1)  provide 
the  Aray  with  a  testbed  to  develop  new  tactically  oriented 
coaputer  Mapping  systeas,  (2)  to  put  digital  Mapping  and 
terrain  analysis  in  the  hands  of  all  professional  terrain 
analysts  and  topographers,  and  (3)  to  provide  prototype 
systeas  that  could  teach  field  users  about  digital  terrain 
aapping. 

A  derivative  parallel  version  of  the  prograa  called 
MICROFIX  operates  on  an  enhanced  Apple  II-*-  (the  AN/UYK-71). 

2.  Accoaplishaents 

The  prograa  was  written  in  Turbo  Pascal  for  an  MS- 
DOS  Microcomputer  with  a  CGA  display,  which  proves  that  a 
aicrocoaputer  environment  can  process  and  display  the 
digitized  data.  MicroDBM  is  adequate  in  breadth  and  depth 
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to  prove  that  a  microcomputer  can  be  used  to  generate  and 
display  maps  which  provide  some  useful  planning  operations, 
as  illustrated  by  the  following  list  of  functions: 

Color  tinted  elevation  maps,  with  seven  user  defined 
categories,  at  any  desired  scale; 

Slope  maps,  with  four  user  defined  categories,  at  any 
desired  scale; 

Contour  maps,  at  any  desired  scale  and  contour  interval, 
and  masked  area  plots  showing  terrain  hidden  from  an 
observer ; 

Topographic  profiles  between  any  two  desired  points,  at 
any  desired  scale  and  vertical  exaggeration; 

—  Oblique  three  dimensional  views  with  any  desired 
orientation ; 

The  capabilities  provided  are  significant,  and  may  become 
part  of  any  tactical  digitized  mapping  system  that  is 
implemented.  However,  the  critical  features  displays  are 
not  available  and  some  of  the  functions  are  not  fully 
developed. 

The  ability  to  use  existing  and  available  DMA  data 
is  also  proved  by  MicroOEM.  By  using  the  DTED  DMA  database, 
the  ability  of  a  microcomputer  to  provide  several  graphic 
displays  of  terrain  elevation  characteristics  is  proven. 
Storing  and  transporting  data  for  the  mapping  system  is  a 
critical  question  that  was  also  addressed.  MicroDBM  proved 
that  the  data  base  can  be  broken  into  units  small  enough  to 
be  carried  on  floppy  disks,  and  still  provide  adequate 
information  to  build  a  usable  map  display. 

3 .  Limitations 

Many  of  the  functions  provided  would  be  useful  and 
valuable  to  an  infantry  officer,  yet  MicroDBM  uses  only 
elevation  data.  Failing  to  use  terrain  features  limits  its 
value . 

It  was  apparently  developed  with  topographic  studies 
in  mind,  not  for  the  tactical  commander's  needs.  As  such, 
it  provides  good  information,  but  lacks  some  of  the 


characteristics  (sost  relating  to  data  manipulation 
regarding  terrain  features)  that  would  aake  it  most  valuable 
in  the  field. 

The  area  displayed  by  the  program  is  a  grid  15*  by 
15',  which  is  an  adequate  size  for  tactical  users.  However, 
the  DTED  database  provides  only  90*  accuracy  of  points  60  - 
120  aeters  apart  East/  West  and  separated  by  92  meters 
North/  South.  Additional  inaccuracies  are  probably 
introduced  in  conversion  to  64,000  points  (320  by  200 
pixels)  for  display  as  individual  pixels  on  the  CGA  display. 
This  resolution  nay  be  adequate  to  represent  the  single 
diaension  of  elevation  data,  but  it  is  not  possible  to 
display  features  as  individual  pixels.  The  systea  is  also 
slow  in  that,  after  the  calculation  that  deteraines  its 
position  in  relation  to  the  data  point  it  represents  has 
been  done,  each  pixel  is  written  to  the  screen  individually. 

C.  EVALUATION 

This  research  is  an  effort  to  determine  if 
microcomputers  can  display  and  use  aap  data  necessary  for 
the  terrain  analysis  that  would  be  performed  by  a  tactical 
commander.  All  of  the  projects  studied  are  related  to  this 
thesis,  yet  the  relationship  is  remote  in  each  case. 

AOALMS  used  the  TTADB  to  display  a  computer-generated 
map,  but  does  not  attempt  to  use  the  features  data 
available.  Vista  is  based  on  the  TTADB  and  displays 
features,  but  is  a  mainframe  coaputer  system  which  is 
capable  of  significantly  greater  tasks  than  a  micro  is 
capable  of  handling.  MicroDEM  has  made  significant  strides 
toward  the  functional  use  of  microcomputer  map  displays  but 
is  missing  the  features  and  resolution  that  are  critical  to 
a  tactical  planner  or  field  coamander. 

These  programs  have  helped  validate  soae  of  the  concepts 
that  this  study  is  aiaed  to  prove;  however,  aany  questions 
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are  not  adequately  addressed.  Can  current  technology 
support  the  resolution  to  display  features  in  addition  to 
elevation?  Can  the  microcomputer  micro-processor  provide 
the  speed  and  power  to  manipulate  larger  data  files  to 
support  large  maps?  Is  the  storage  media  capable  of 
survival  in  a  field  environment,  and  providing  storage  of 
the  large  amounts  of  data  required? 
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IV.  TACTICAL  DIGITAL  MAPPING  SYSTEM  PROTOTYPE 


To  develop  an  understanding  and  to  provide  a  graphical 
tool  reviewing  the  probleas  of  a  digitized  mapping  systea, 
the  Tactical  Digital  Mapping  Systea  Prototype  (TDMS)  was 
developed.  The  systea  was  not  intended  to  be  a  fully 
developed  system,  but  merely  an  exploration  of  concepts. 

The  MicroDEM  systea  provides  an  excellent  example  of  the 
possibilities  of  microcomputer  based  digitized  mapping.  It 
did  not,  however,  show  an  operationally  oriented  environment 
nor  did  it  include  the  features  data  required  of  a  fully 
functional  system.  It  was  not  the  intention  of  the 
researchers  to  duplicate  the  efforts  of  the  MicroDEM  systea 
but  to  develop  three  concept  areas.  First  it  was  desired  to 
explore  the  possibilities  of  the  outward  systea  appearance 
to  the  user.  Second  it  served  as  a  vehicle  to  develop  an 
appreciation  of  the  display  requirements  and  limitations. 
Finally,  it  forced  an  applied  study  of  the  data  requirements 
discussed  in  Chapter  III  as  well  as  providing  an  insight  to 
undeveloped  data  requirements.  The  complete  prototype 
program  listing  is  provided.9 

A.  DESCRIPTION 

The  Tactical  Digitized  Mapping  System  prototype  was 
written  in  the  'C*  language.  The  program  consists  of  three 
aajor  areas;  a  program  shell  divided  into  functional  areas, 
a  portion  that  consolidates  the  user  requested  data,  and  a 
display  section.  In  operation,  the  user  is  guided  by  menus 
to  input  grid  coordinates  and  then  a  map  is  produced  and 
displayed.  The  display  is  a  full  color  nap  of  five  square 
kilometers  with  features  and  elevation  represented.  The 

9 .  See  Appendix  G . 
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system  was  designed  to  work  on  an  IBM  PC  or  compatible  with 
an  EGA  display.  All  files  for  the  program  must  be  located 
on  the  same  drive  to  operate.  The  prototype  is  not  intended 
to  be  fully  functional  but  merely  to  illustrate  the  look  and 
feel  of  the  implemented  system. 

B.  DATA 

The  prototype  served  as  an  instrument  for  determining 
the  data  format  requirements.  In  addition  to  the 
considerations  of  Chapter  II,  the  structural  layout  of  the 
map  data  files  needed  to  be  determined.  Bach  one  kilometer 
block  of  data  was  placed  in  an  individual  file.  The 
filename  indicated  the  grid  coordinate  of  the  data.  For 
example,  D6008.DAT  indicated  a  data  file  of  the  one 
kilometer  square  with  the  lower  left  hand  grid  coordinate 
6008.  To  assemble  larger  map  units  the  files  were 
consolidated.  The  use  of  the  grid  coordinate  in  the 
filename  allowed  the  mathematical  manipulation  of  filenames 
to  determine  or  isolate  desired  files.  To  create  a  four 
square  kilometer  map  with  the  grid  coordinate  6008  at  the 
lower  left  hand  corner,  one  is  added  to  6008  to  determine 
the  upper  left  hand  corner,  101  is  added  for  the  upper  right 
and  100  for  the  lower  right.  An  ’M’  replaced  the  ’D’  to 
designate  a  composite  map  data  file,  M6008.DAT. 

While  combining  one  square  kilometer  data  files  is  a 
practical  approach  to  manipulating  data  files,  it  is  also 
alow.  To  consolidate  an  eight  square  kilometer  file,  with 
an  AT  accessing  files  on  a  RAM  disk,  required  six  seconds. 
Even  with  an  optimized  routine,  which  this  was  not,  the 
consolidation  operation  for  a  100  square  kilometer  map  may 
be  slower  than  desired.  One  alternative  may  be  to  build 
bigger  basic  building  blocks.  The  difficulty  with  this 
approach  is  that  all  operations  will  now  have  to  deal  with 
the  larger  blocks,  not  just  the  consolidating  routine.  The 


larger  blocks  in  soae  cases  will  require  sore  data  to  be 
transferred  than  the  saaller  blocks.  A  lore  promising 
approach  Bay  be  to  use  the  data  directly,  when  appropriate, 
without  consolidating  files.  A  faster  central  processing 
unit  (CPU)  and  Baking  full  use  of  techniques  for  fast  aeaory 
transfers  aay  reduce  this  problea  to  an  acceptable  level.10 

The  one  kiloaeter  data  blocks  provide  a  logical  base  for 
data  searches  and  extractions.  By  using  a  one  kiloaeter 
block  a  logical  addressing  systea  is  easily  prograaaed. 
Searches  and  extractions  can  be  given  in  teras  of  grid 
addresses.  The  Military  Grid  Reference  Systea  equally 
divides  a  grid  coordinate  between  the  kiloaeters  east  of  an 
ordinate  and  the  kiloaeters  north  of  that  ordinate.  That 
is,  the  coordinate  614825  is  61.4  kiloaeters  east  of  the 
000000  coordinate  and  82.5  north.  To  exploit  this 
characteristic,  a  data  block  should  be  a  square  oriented  on 
an  evenly  aatched  coordinate  pair.  For  exaaple,  the 
coordinate  pair  68  would  represent  a  square  with  sides 
running  east  froa  60  to  69.9  and  north  froa  80  to  89.9.  The 
next  choice  would  be  the  four  digit  coordinate  pair  6182 
which  represent  a  square  kiloaeter.  Using  this  aethod, 
orderly  addressing  algorithas  can  be  developed  and  user 
input  does  not  have  to  be  translated  into  an  entirely 
different  addressing  scheae.  As  the  two  digit  coordinate 
pair  results  in  a  100  square  kiloaeter  block  and  the  six 
digit  pair  results  in  a  .01  kiloaeter  square,  the  four 
digit,  one  kiloaeter  square  is  the  logical  file  block  size. 

C.  OPERATION 

1 .  General 

Any  systea  for  wide  general  ailitary  use,  Bust  be 
suited  for  the  coaputer  illiterate  with  a  high  school 
diploaa.  Rapid  turnover  of  personnel  puts  eaphasis  on 


See  Chapter  V. 


ainiaizing  training  requireaents .  If  the  systea  cannot 
deliver  on  the  unstated  pledge  of  faster  results  and  ease  of 
use,  there  will  be  little  acceptance.  While  the  systea  aay 
have  aany  capabilities,  each  individual  user  should  be  able 
to  access  and  run  his  application  without  undue  stress  and 
with  a  ainiaua  of  instruction.  There  is  nothing  to  prohibit 
the  developaent  of  a  fully  functional  systea  with  a  poor 
user  interface,  but  addressing  these  issues  is  essential  to 
providing  a  quality  product.  The  prototype  environaental 
shell  was  conceived  to  have  a  targeted  user  environaent, 
with  no  requireaent  for  extensive  coaputer  knowledge  on  the 
part  of  the  routine  user.  The  coaaon  practice  of  providing 
an  error  checked,  aenu  driven  systea  was  followed.  When  the 
targeted  user  is  in  the  systea  he  should  have  no  concerns 
about  coaputer  systea  issues.  As  long  as  the  user  can  read 
and  knows  his  job,  the  systea  aust  not  provide  hia  with 
technical  or  iapossible  deaands.  The  prototype  systea  is 
able  to  do  this,  but  a  full  systea  aay  have  difficulties. 

The  prototype  was  designed  for  one  coaputer  environaent 
only,  had  no  conflicting  hardware  requireaents  (e.g.  Bouse 
or  keyboard,  Bonochroae  or  color),  and  dealt  with  relatively 
siaple  operations. 

By  way  of  contrast,  the  MicroDEM  systea  provides  a 
general  systea  which  can  be  configured  in  a  variety  of  ways. 
The  nuaerous  capabilities  of  the  systea  require  the  user  to 
establish,  or  aaintain,  the  proper  environaent,  steer 
through  general  systea  aenus  and  know  and  recall  specific 
coaaands  relating  to  various  prograa  portions.  The 
researchers  experienced  probleas  in  doing  soae  routine  tasks 
and  were  thrown  by  several  environaental  set  up  issues.  Had 
the  MicroDBM  prograa  been  written  for  specific  equipaent, 
tasks,  and  users  with  ease  of  use  as  a  priority  none  of 
these  probleas  would  have  developed.  If  the  user  only  had 
to  select  froa  aenus  of  iteas  he  is  faailiar  with,  and 


coaaands  and  instructions  were  available  and  consistent,  the 
user  could  not  aake  aistakes.  This  is  not  to  criticize  the 
systea,  which  is  not  a  finished  product  or  an  application 
for  a  specific  use.  The  point  is,  that  had  siaplicity  of 
use  been  a  priority  in  the  developaent  of  MicroDBM,  the  saae 
systea  which  is  troublesoae  for  a  coaputer  literate  could  be 
quite  friendly  for  the  novice  user. 

2 .  Title  Screen 

When  the  systea  is  started  the  TDMS  title  screen  is 
displayed.  After  a  tiaed  delay  or  a  key  press,  the  screen 
is  cleared  and  the  aain  aenu  is  displayed.  In  the  full 
iapleaentation,  this  screen  could  be  used  to  display  general 
inforaation  such  as  security  requireaents  or  operating 
restrictions . 

3 .  Main  Menu 

The  aain  aenu  displays  five  choices  representing 
four  of  the  functional  areas  of  a  battalion  or  regiaental 
staff  and  an  exit  option.  By  selecting  one  of  these  the 
user  is  put  into  a  subsystem  tailored  to  that  functional 
area  or  is  exited  froa  the  systea. 

In  developing  the  systea  shell,  the  concept  of  how 
the  systea  would  be  used  operationally,  while  not  entirely 
within  the  scope  of  the  study,  had  to  be  addressed.  The 
targeted  users  are  priaarily  the  coaaanders  and  staff  of 
Marine  battalions,  regiaents,  and  divisions.  The  principle 
tactical  aap  data  processors  of  these  organizations  are  the 
operations  officer,  intelligence  officer,  the  fire  support 
coordination  center  staff  and  the  logistics  officer.  Bach 
of  these  have  unique  but  siailar  requireaents  for  data 
aanipulation  and  the  output  of  one  nay  be  the  input  to 
another.  It  was  therefore  logical  that  the  systea  be 
divided  into  aodules  for  each  functional  area.  Since  each 
functional  aodule  shares  aany  of  the  saae  requireaents,  it 
is  logical  that  they  share  coaaon  subordinate  aodules.  For 


the  prototype,  the  system  was  completely  integrated.  The 
issue  that  aust  be  resolved  in  an  implemented  system  is;  how 
far  should  integration  go?  Should  four  distinct  functional 
area  systems  be  developed  or  can  one  system  handle  all  the 
requirements  without  growing  too  large?  In  a  shared 
environment  do  some  users  need  to  be  limited  in  their  access 
to  system  features? 

4 .  Functional  Areas 

Three  of  the  functional  areas  (intelligence, 
operations,  and  logistics)  display  a  menu  with  the  following 
choices: 


View  Nap  -  Displays  a  map  chosen  by  the  user. 

Plot  Map  Data  -  This  module,  when  implemented,  will 
display  a  user  selected  map  and  will  allow  the  user  to 
plot  data  on  the  map.  The  items  to  be  plotted  should  be 
available  from  a  large  list  selection  of  tactical, 
coordination,  natural  and  man-made  features.  The  data 
files  will  be  updated  by  this  function. 

Bxtract  Data  -  When  implemented,  this  module  allows  the 
user  to  extract  the  location  of  selected  features  or  to 
extract  feature  data  of  a  given  point.  By  entering  grid 
coordinates,  the  user  will  receive  all  of  the  data 
listed  for  the  location  indicated.  By  specifying  a 
search  area  and  features  to  be  looked  for,  (hill  tops, 
bridges  etc.),  the  user  will  receive  the  grid 
coordinates  that  meet  the  specifications. 

Update  Data  -  The  implementation  of  this  module  will 
take  coordinates  and  data  specifications  and  alter  the 
data  records. 

Bxit  -  Exits  functional  area  and  returns  to  main  menu. 


The  fourth  functional  area  is  slightly  different, 
although  they  all  may  be  different  in  the  full 
implementation.  The  fire  support  area  will  perform  the 
following  functions  when  implemented: 


List  of  Targets  -  This  module  will  create  or  display 
target  lists.  Lists  will  be  created  by  plotting  on  a 
map  or  by  extracting  from  map  files.  The  display  mode 
will  produce  a  text  listing  or  a  map  display. 

Coordination  Lines  -  This  module  will  display  a  map  for 
review  or  updating  of  fire  support  coordination  lines 
and  information. 


Maps  -  Situation  -  Displays  the  sap  produced  by  the 
operations  function. 

Maps  -  Intelligence  -  Displays  the  aaps  produced  by  the 
intelligence  function. 

Exit  -  Exits  functional  area  and  returns  to  aain  senu. 

While  each  of  the  functional  areas  will  utilize 
siailar  prograa  code,  each  has  particular  data  needs  and 
interests.  To  separate  the  data  of  each,  unique  file  naaes 
will  be  used  for  each  use.  For  exaaple,  Do6008.dat  and 
Mo6008.dat  could  be  used  for  operations  data  while 
DL6008.DAT  and  ML6008.DAT  could  be  used  for  logistics.  Of 
aore  concern  to  the  researchers  than  keeping  data  separate 
was  the  issue  of  data  integrity.  This  subject  is  beyond  the 
scope  of  this  study  but  will  have  to  be  addressed  in 
iapleaentation . 

Additional  aodules  required  should  be  deterained  by 
analysis  of  the  users  needs.  The  view  of  the  researchers 
was  that  all  desired  aajor  functions  Bay  be  aet,  but  all 
possible  uses  cannot  be  accoaaodated.  The  autoaated  systea 
cannot  natch  the  flexibility  of  the  hunan  with  a  paper  nap. 
It  can  though  provide  services  not  available,  such  as  three 
diaensional  views. 

5 .  View  Man 

The  view  aap  nodule,  actually  the  CREATE. BXB  file, 
as  iapleaented  provides  the  user  with  a  choice  of  displaying 
an  old  aap,  creating  a  new  one  or  exiting  back  to  the 
functional  area  aenu.  If  the  user  chooses  to  display  an  old 
aap,  the  four  digit  coordinate  of  the  lower  left  hand  corner 
is  requested  and  the  'M'  file  is  displayed.  In  the  full 
iapleaentation  the  aaps  available  on  the  current  or  selected 
drive  would  be  listed,  froa  which  the  user  aay  select.  If 
the  user  is  creating  a  new  nap  the  four  digit  coordinate  ia 
requested,  the  ’M’  file  is  created  and  the  aap  displayed. 

In  the  final  iapleaentation,  the  old  aap  routine  will  have 


to  sake  allowances  for  outdated  'M*  files,  possibly  through 
their  destruction  when  any  of  their  component  *D’  files  are 
altered.  The  old  aap  usage  is  important  in  that  the  speed 
of  the  new  aap  creation  aay  take  considerably  longer. 

The  display  issues  were  of  priaary  concern  in 
developing  the  prototype.  These  issues  are  sore  coaplex 
than  those  of  aere  data  aanipulation.  Two  questions  in 
particular  needed  to  be  answered;  how  auch  data  could  be 
displayed  and,  aore  iaportantly,  could  the  data  be 
intelligently  displayed?  Bnhanced  Graphics  Adapter  (EGA) 
aode  was  utilized  because  of  the  increased  resolution  over 
Color  Graphics  Adapter  (CGA)  and  the  iaportance  of  color, 
not  available  in  aonochroae  node,  as  a  tool  to  convey 
inforaat ion. 

The  BGA  display  has  640  pixels  horizontally  and  350 
vertically.  Conceptually,  this  allows  a  aaxiaua  of  224,000 
points  or  560  square  kiloaeters  of  400  points  each.  To  pass 
conprehendible  inforaation  though,  soae  systea  of  syabols 
must  be  used.  The  standard  text  characters  are  eight  pixels 
by  fourteen,  allowing  for  2000  separate  points  on  a  screen 
of  five  square  kiloaeters.  The  standard  character  set  was 
used  in  the  prototype.  It  was  successful  at  passing  the 
inforaation  for  each  point  but  had  three  liaitations. 

First,  the  standard  text  characters  obviously  do  not  look 
like  aap  syabols.  Additionally,  the  eight  by  fourteen  pixel 
arrangeaent  distorts  the  square  grid  into  a  rectangle.  Most 
iaportantly,  five  square  kiloaeters  is  an  unacceptably  saall 
section  of  aap.  To  correct  these  liaitations,  square,  user 
defined,  aap  characters  aust  be  created  and  used.  First, 
the  deterainat ion  aust  be  aade  as  to  the  size  required  for 
each  point.  The  saaller  the  character  is,  the  less  capable 
we  are  of  creating  unique  distinguishable  syabols.  A  larger 
character  aeans  greater  flexibility  for  designing  syabols 
but  less  aap  coverage.  A  four  by  four  or  five  by  five  pixel 
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character  would  allow  for  sufficient  character  aet  size 
without  points  becoming  too  course  or  too  small.  This  would 
provide  for  thirty  five  to  twenty-two  square  kilometers  to 
be  represented  at  any  tiae. 

The  possible  four  by  eight  kiloaeter  sap,  achieved 
by  using  a  four  by  four  pixel  character  set,  does  not 
provide  an  adequate  size  aap  display.  An  alternative  aethod 
to  increase  the  point  density  would  be  to  display  the  coaaon 
inforaation  froa  aore  than  one  point  as  a  single  syabol.  To 
do  this,  when  a  foraat  file  was  being  created,  a  point  would 
have  to  be  coapared  with  its  neighbors  to  deteraine  if  they 
possessed  the  saae  characteristic.  This  would  increase  the 
nuaber  of  points  that  could  be  displayed  but  requires  a 
significant  increase  of  coaparisons  and  aeaory  accesses, 
slowing  down  processing.  A  combination  of  the  smaller 
characters,  group  syabol  representation  and  an  improved, 
higher  resolution,  monitor  aay  be  necessary  to  produce  a 
satisfactory  display.  If  a  solution  cannot  be  reached,  the 
value  of  an  automated  mapping  system  without  graphic 
displays  must  be  assessed. 

Further  complicating  the  display  problem  are 
people’s  perception  of  what  features  should  look  like  on  a 
aap.  A  road,  railroad,  or  electrical  line  is  thought  of  as 
a  continuous  line.  Using  the  saae  character  for  North  - 
South  roads  as  Bast  -  West  roads  fails  to  produce  the 
continuous  line  representation  desired.  Road  junctions 
should  look  like  road  junctions  and  bridges  should  be 
oriented  the  saae  direction  as  the  roads  they  support.  To 
aake  this  happen  will  require  three  things;  aore  than  one 
character  per  feature  aust  be  available,  aeaory  Bust  be  held 
of  the  features  around  a  point,  and  the  logic  aust  associate 
the  neighboring  features  and  pick  the  appropriate  character. 
EGA  is  capable  of  using  1024  characters,  but  the  aeaory  and 
logic  requirements  will  be  difficult  to  Beet  adequately. 


Without  a  finer  display,  the  result  still  will  not  be  saooth 
since  characters  cannot  be  Bade  for  orientation  to  every 
point  of  the  coapass. 

The  use  of  color  proved  to  be  extreaely  beneficial. 
Color  was  used  to  indicate  water  and  changes  in  elevation. 
Color  served  this  function  well  since  few  aeaory  variables 
were  needed  to  keep  track  of  base  points.  Their  nuaeric 
values  were  then  used  for  increaenting  and  decreaenting 
elevation  strata.  The  alternative  use  of  contour  lines 
would  have  required  the  storing  and  coaparing  of  each  four 
neighboring  points.  This  would  be  needed  to  deteraine  when 
and  where  lines  were  to  be  drawn  for  each  relationship  of  a 
point  to  its  neighbor.  This  is  not  only  aore  tiae  and 
aeaory  intensive  but  also  confuses  the  aap  syabol  issue  as 
well.  Two  possible  advantages  of  utilizing  contour  lines 
would  be  to  free  color  to  represent  other  uses  or  to  show 
elevation  on  a  aonochroae  display.  The  use  of  color  for 
elevation  contouring  is  in  the  researchers*  opinion  the  best 
use  of  this  asset  with  the  test  hardware. 

D.  EVALUATION 

The  prototype  operated  as  desired  and  indicated  that  the 
developaent  of  a  usable  systea  is  technically  possible.  The 
use  of  one  square  kiloaeter  data  files  and  the  use  of  color 
coding  of  elevations  were  concluded  to  be  sound  approaches. 
The  researchers  also  deterained  that  the  aicrocoaputer 
hardware  used  was  not  capable  of  producing  a  display  of  a 
sufficiently  large  area.  If  a  display  capable  of  giving  a 
large  aap  coverage  is  used,  it  is  conceivable  that  the 
extraction  of  the  data  for  the  display  will  be  unacceptably 
slow.  Saaller  less  environaental ly  deaanding  equipaent  than 
that  used  with  the  prototype,  such  as  laptops,  would  be 
incapable  of  supporting  the  iapleaented  systea  at  this  tiae. 
Accordingly,  use  of  the  envisioned  systea  below  the 


battalion  level  ia  not  practical  and  the  use  of  the  aystea 
will  be  liaited  at  all  levels  by  environaental  conditions. 


V.  HARDWARE  CONSIDERATIONS 

The  ability  of  microcomputers  to  do  the  necessary 
calculations,  the  ability  of  storage  aedia  to  survive  the 
environment  and  hold  enough  data  to  be  useful,  and  the 
capabilities  of  current  display  technology  to  provide 
adequate  resolution,  are  a  few  of  the  most  important 
hardware  questions  that  need  to  be  answered  if  digital 
mapping  systems  are  to  be  implemented  for  general  use. 

A.  CPU  CALCULATING  SPEED 

The  researchers  came  to  the  realization  during  this 
study  that  the  CPU  of  a  computer  and  it's  calculating 
capabilities  are  extremely  important  to  a  project  such  as 
this.  The  time  required  to  generate  the  graphics  screens, 
sort  the  data  base,  combine  the  data  sectors,  and  do  the 
matrix  calculations  to  present  map  overlays  will  weigh  very 
heavily  on  the  computer  and  its  CPU.  It  is  suspected  that  a 
complete  implementation  of  a  TDMS  would  be  practically 
unusable  on  a  PC,  an  XT,  or  one  of  the  portables  that  run  an 
8088  or  8086  at  4.77  MHz.  The  "turbo  XT"  clones  would  be 
very  little  better  under  most  loads  of  this  system.  In  fact 
the  AT  and  "turbo  AT”  clones  might  prove  sluggish  in  many 
cases.  However,  there  is  a  ray  of  sunshine  in  the  new  80386 
CPU.  It  is  relatively  new  technology,  and  as  such  the 
boundaries  of  its  capabilities  are  just  beginning  to  be 
explored. 

1 .  PC's.  XT's,  and  Clones 

The  IBM  PC  was  announced  12  August  1981  and  the  PC 
XT  on  8  March  1983.  These  machines  started  a  revolution  in 
the  world  of  computing.  It  provided  the  ability  to  increase 
productivity  of  the  user,  while  not  requiring  any  more  (and 
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often  tiaes  auch  less)  work.  But,  the  engineers  were 
conservative  in  their  designs  for  aany  reasons.  The 
coaponents  (specially  aeaory  chips)  were  extreaely 
expensive,  which  aade  justification  of  a  state-of-the-art 
design  difficult.  Therefore,  a  leisurely  speed  of  4.77  MHz 
was  used  on  the  eight  bit  bus  for  the  Intel  8088. 

2 .  IBM  AT.  AT  Compatibles,  and  Turbo  AT’s 

The  IBM  AT  was  announced  14  August  1984,  which 
boosted  the  personal  coaputer  into  another  diaension;  the 
Intel  80286  CPU.  This  vastly  iaproved  cousin  of  the  8088 
which  was  the  heart  of  the  PC  and  XT,  ran  aore  efficiently 
through  iaproved  aicro-circuitry  and  iaproved  aicro-code  as 
well  as  the  awesoae  speed  of  a  6  MHz  clock  chip.  The  AT’s 
sixteen  bit  bus  could  handle  aore  coaplex  instructions  aore 
efficiently  producing  twice  the  throughput. 

Hackers  soon  discovered  that  the  80286  would  run 
faster  if  the  12  MHz  clock  chip  (which  is  stepped  down  50* 
in  circuitry)  was  replaced  with  a  16,  a  17,  an  18  or  even  up 
to  a  20  MHz  chip.  The  clone  aakers  quickly  responded  with 
technology  siailar  to  the  turbo  XT’s,  producing  the  turbo 
AT’s  soae  of  which  are  now  being  aarketed  as  14  and  16  MHz 
aodels . 

3 .  386  Machines 

The  Intel  80386  CPU,  a  32  bit  aeaber  of  the  8088 
faaily  was  another  order  of  aagnitude  faster  in  coaputations 
than  even  the  80286.  The  faster  clock  allowed  a  aore 
efficient  CPU  to  handle  aore  32  bit  words  and  instructions 
in  one  second.  "Coaparing  its  Deskpro  386  with  an  AT, 

Coapaq  says  it’s  two  to  three  tiaes  as  fast  (the  PC  Magazine 
Labs  benchaark  teat  confiraed  it’s  at  least  twice  as  fast  as 
a  PC  AT)  and  as  auch  as  ten  tiaes  as  fast  with  32-bit 
software. " (Howard  and  Hong,  1986,  p.  136) 

But  the  speed  has  increased  even  aore  with  the 
recent  release  of  20  MHz  386  aachines,  and  there  are  ruaors 
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of  25  MHz  machines  in  test,  not  to  aention  the  ruaors  of  the 
80486  processor  nearing  completion  of  design.  The  Coapaq 
uses  128  K  of  RAM,  "...to  keep  a  copy  of  the  EGA  ROM  BIOS 
that  supports  the  BGA.  Access  to  the  BGA  using  the  RAM- 
based  BIOS  is  faster  because  the  copy  resides  in  32-bit 
aeaory,  which  runs  twice  as  fast  as  aeaory  that  is  located 
on  the  8  or  16-bit  bus.  Some  video  operations  can  be  up  to 
twice  as  fast .”( Howard  and  Wong,  1986,  p.  138)  The  recent 
announceaent  of  an  IBM  386  based  machine  aay  further  spur 
developaent  that  will  push  technology  forward. 

Other  recent  advances  in  technology  have  improved 
the  possibility  of  a  TDMS's  success.  The  release  of  Phar 
Lap  Software's  386/ASM/LINK,  which  fully  supports  the  32-bit 
capabilities  of  the  386  machines  is  one  example.  This  will 
allow  any  programs  written  in  or  assembled  under  this 
assembler  to  use  the  faster  32-bit  aeaory  data  path  for  much 
faster  (as  much  as  ten  times  faster  according  to  Compaq 
Corp.)  operations.  The  set  of  development  programs  in  this 
package  will  provide  tools  to  improve  and  speed  program 
developaent  on  the  386  architecture. (Trask,  1987,  pp.  224- 
227) 


Thus  the  state-of-the-art  technology  which  offers 
the  kind  of  speed  that  aay  be  required  to  operate  a  TDMS  in 
its  full  implementation  at  reasonable  speeds  is  available. 
It  would  at  the  very  least  be  a  very  dramatic  improvement 
over  the  systems  used  to  develop  the  prototype  which  were 
state  of  the  art  at  the  beginning  of  this  study.  We  cannot 
imagine  what  tomorrow  aay  bring,  but  surely  it  will  improve 
the  operating  speeds  for  a  TDMS. 


B. 


STORAGE  MEDIA 

Storage  media  used  in  any  project  is  dictated  by  the 
equipment  used  and  the  environment  it  must  endure.  There 
are  many  types  of  media  that  are  capable  of  providing  the 
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storage  necessary  for  a  digital  sapping  system  cosputer  in 
the  field,  but  not  sany  that  could  survive  the  environaent. 
The  media  used  would  have  to  be  able  to  endure  every  extreme 
in  rough  handling,  humidity,  dirt  and  dust,  moisture,  and 
temperature.  These  conditions  would  prove  deadly  to  many 
means  of  data  storage.  However,  several  media  available 
today  would  survive  this  kind  of  treatment  and  provide 
usable  data  for  a  TOMS. 

1 .  Defense  Mapping  Agency  Data  Storage 

Presently  DMA  data  is  available  only  on  nine-track 
tape  which  is  not  a  good  media  for  field  use,  or  even  for 
microcomputer  use.  The  TTADB  data  for  a  single  grid 
measuring  1  kilometer  by  1  kilometer  (or  80  data  points  by 
80  data  points)  requires  524,902  bytes  of  storage  space. 

This  data  can  be  significantly  trimmed  by  removing  many 
unused  or  unnecessary  data  bits,  at  which  time  it  could 
easily  be  transferred  to  any  chosen  storage  media.  But  the 
data  for  one  full-screen  map  display  of  100  square 
kilometers  in  the  format  defined  in  Chapter  II,  will  still 
require  240  KB  storage  space. 

2 .  Floppy  Disk 

The  TDMS  data  storage  requirement  for  one  kilometer 
square  grid  is  3400  bytes. 

TABLE  3.  GRID  STORAGE  CAPABILITIES 
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Media _ Size _ No.  Grids 


5  1/4  in  HD  Disk 

1.2  MB 

370 

3  1/2  in  Disk 

720  KB 

216 

3  1/2  in  Disk 

1.44  MB 

444 

Hard  Disk  Drive 

20  MB 

6168 

CD-ROM  Disk 

550  MB 

169,622 

WORM  Drive 

200  MB 

61,680 

Laser  Card 

2  MB 

615 

This  aeans  that  one  CD-ROM  will  hold  Bap  data  for  terrain 
the  size  of  the  state  of  Washington. 

This  would  indicate  that  storage  of  a  standard 
1:50,000  aap  in  digital  fora  would  not  be  optiaized  on  a 
floppy  disk  of  any  above  aentioned  size.  Yet  with  aultiple 
disk  sets  the  space  is  available  on  floppy  disk  to  provide 
these  digital  Baps. 


Floppy  disks  and  tape  share  the  characteristic  of 
operating  with  the  head  in  contact  with  the  aediua. 

Floppy  disks  were  originally  intended  to  load  prograas  for 
aainfraae  coaputers  and  did  not  need  to  survive  aany 
passes.  They  are  presently  the  aain  aediua  for 
aicrocoaputer  archival  storage.  This  Bakes  friction  and 
wear  characteristics  very  iaportant.  High-quality  floppy 
disks  are  now  burnished,  in  the  Banner  of  Winchester  disks 
to  assure  saoothness  and  absence  of  particles  that  Bight 
break  off  and  scratch  the  disk.  Heads  are  aade  of  hard 
ferrites  eabedded  in  hard  ceraaic  sliders. 


The  reaaining  culprits  for  floppy  failures  are  dirt 
and  physical  daaage.  All  these  problens  are  solved  by  the 
newer  3  1/2-inch  Floppy  foraat,  which  uses  a  rigid  jacket, 
a  sliding  aetal  shutter  to  cover  the  access  slots,  and  a 
metal  hub  attached  to  the  plastic  disk.(Laub,  1986,  p. 

168) 


A  floppy  disk,  of  any  ilk,  will  succuab  to  the  heat,  dirt 
and  dust,  or  aoisture  of  the  field  environaent  in  a  very 
short  tiae. 

3 .  Hard  Disk  (Winchester  Drives) 

The  aost  faailiar  storage  aedia  that  offers  the 
needed  storage  space  is  the  hard  disk  (or  Winchester  drive), 
which  has  proven  since  their  use  in  aicrocoaputers  began,  to 
be  quite  durable  in  an  office  environaent.  However,  a  hard 
disk  as  we  know  then  today,  would  probably  not  survive  aore 
than  a  few  days  in  the  field  because  of  critical  power 
requirenents  and  the  delicate  nature  of  the  platters.  "With 
tolerances  slightly  above  the  angstroa  level,  dropping  a 
chassis  a  quarter-inch,  or  tapping  it  with  your  toe,  is  the 
hard  disk  equivalent  of  an  aton  boab  going  off  directly 
overhead. "(Sonerson,  1987,  p.  200)  One  gentle  buap  is 


enough  to  cause  the  Winchesters  "flying  head"  to  crash  into 
the  platter,  permanently  destroying  the  data  at  that 
position,  and  possibly  destroying  the  entire  drive  unit. 

One  power  surge  or  voltage  drop  can  have  the  same  results. 

A  hard  disk  is  the  fastest  media  that  has  the 
capability  to  store  that  amount  of  data  necessary  for  TONS 
with  some  average  access  time  at  13  mi 1 i-seconds .  It  also 
offers  the  ability  to  both  read  and  write  data  which  is  an 
absolute  necessity  for  the  TOMS  as  described  in  Chapter  IV. 

4 .  Tape  Cartridge 

A  tape  cartridge  might  be  acceptable.  Having  a 
thick  aluminum  base  plate  and  a  hard  plastic  case  with  a 
door  to  protect  the  tape  from  dirt  and  damage  it  might 
survive  the  harsh  environment.  Some  tape  cartridges  store 
over  100  MBytes  in  paperback  book  size  cases,  while  the 
smaller  "DC2000  cartridges...  let  you  tote  40  megabytes  of 
formatted  data  in  your  shirt  pocket ." (Rosch,  "DC2000 
Systems:  Pocket-Size  Backup",  1987,  p.  Ill)  Yet  the  primary 
purpose  of  a  tape  cartridge  unit  is  as  a  hard  disk  drive 
backup  system.  Not  being  designed  for  random  access  storage 
tape  units  are  very  slow  finding  specific  data,  but  are 
quite  good  at  sequential  storage  methods.  In  conjunction 
with  microcomputers  a  tape  unit  normally  has  another  medium 
(a  hard  drive)  to  transfer  the  tape  data  to,  without  which 
the  tape  is  very  clumsy  or  even  impossible  to  use.  A  hard 
drive  has  already  been  ruled  out  for  a  field  deployable 
computer  because  of  its  short  life  expectancy,  so  a  tape 
unit  may  also  be  considered  unacceptable. 

5 .  Integrated  Circuit  Card 

An  IC  Card  is  a  credit  card  size  unit  that  contains 
one  or  many  integrated  circuit(s)  physically  in  the  card. 
These  however,  are  limited  to  64  KB  of  information  in  a  unit 
that  is  all  memory.  This  is  inadequate  storage  for  any  but 
a  minuscule  digitized  map  data  base. 


The  aost  promising  technology  is  laser  optical 
storage  media.  Optical  storage  aedia  fall  into  four 
catagories;  Erasable  Optical  Disks,  CD-ROM  (Compact  Disk  - 
Read  Only  Meaory) ,  WORM  (Write  Once  -  Read  Many)  disks,  and 
Optical  Meaory  Cards. 


The  technology  itself,  which  uses  finely  focused  laser 
beaas  to  craa  at  least  50  tiaes  aore  data  onto  a  given 
nuaber  of  square  inches,  aay  bring  aany  aainfraae-scale 
applications  onto  your  desk. 


Apart  froa  their  data  density,  optical  aedia  have 
other  inherent  advantages.  Because  they  are  read  by  a 
light  beaa,  the  reading  aechanisa  can  be  considerably 
farther  away  froa  the  recording  surface,  Baking  head 
crashes  a  thing  of  the  past.  The  surface  can  also  be 
protected  froa  physical  daaage  like  fingerprints  and 
scratches  by  a  transparent  plastic  coating.  And  the 
incredible  bits-to-burn  data  capacity  aeans  that  data  can 
be  recorded  with  a  great  deal  or  redundant  error-checking 
inforaation.  so  that  even  if  a  part  of  the  disk  (aedia)  is 
physically  aaaaged,  actual  data  loss  can  be 
ainiaal. (Helliwell ,  1986,  p.  149) 


This  would  indicate  that  optical  aedia  can  get 
dirty,  be  treated  roughly,  or  get  wet  and  still  be  usable  if 
soae  ainiaua  aeasures  of  cleanliness  (such  as  wiping  off 
dirt  and  aoisture  before  inserting  the  disk  in  the  drive) 
are  observed.  The  treaendous  aaount  of  storage  Bade 
available  would  store  a  vast  aaount  of  aap  data  to  produce  a 
very  large  aap  display  set. 

a.  Erasable  Optical  Disk 

The  erasable  optical  disk  is  still  in  its 
infancy.  Much  research  and  developaent  is  being  carried  out 
with  soae  coapanies  in  design  and  testing  stages.  Many 
experts  believe  that  in  the  1990’ s  this  technology  will  be 
coaaon  place.  The  CD-ROM  and  WORM  drives  are  readily 
available  today  froa  a  nuaber  of  manufacturers  and 
integrators . 


b.  Compact  Disk-  Read  Only  Meaory  (CD-ROM)  Disk 

"A  CD  ROM  can  hold  about  550  Megabytes  of  usable 
data--equivalent  to  over  400  of  the  high-density  1.2 
Megabyte  disks  used  by  the  PC  AT  or  to  over  1,500  old- 
fashioned  360K-byte  d i sks . " ( He  1 1 i we  1 1 ,  1986,  p.  150)  In  his 
description  of  optical  disk  storage  of  the  United  States 
Census  Bureau's  Dual  Independent  Map  Encoding  (DIME)  digital 
Map  data  system,  Donald  Cooke  said: 

Including  the  nuaber  of  characters  needed  to  store 
street  naaes,  node  numbers,  and  so  on,  each  segment 
requires  under  100  bytes  of  storage.  The  nation-wide  file 
will  therefore  contain  between  1  billion  and  1.5  billion 
bytes  of  data.  The  100-byte  record  size  is  generous; 
applying  some  compression  tricks  could  reduce  this  by  more 
than  50  percent.  For  example.  the  high  end  of  an  address 
range  can  be  represented  relative  to  the  low  end,  saving  a 
couple  of  bytes,  or  a  central  street-name  inventory  can 
serve  all  the  street  segments,  rather  than  repeating  the 
street  name  in  each  record.  the  net  result  is  that  it  is 
possible  to  compress  a  digital  street  map  containing  all 
the  streets  in  the  country  to  fit  comfortably  on  one  550- 
megabyte  CD-ROM  disk. (Cooke,  1987,  p.  132) 

These  drives  are  quite  inexpensive,  and  are 
currently  available  for  under  $1000  for  a  CD-ROM  drive  and 
under  $2500  for  a  WORM.  But  the  disks  are  another  natter. 

Custom  CD  ROM  applications  demand  a  hefty 
investment.  Lewis  Miller,  vice  president  of  Marketing  at 
Knowledge  Access,  an  electronic  publishing  firn  in  Mountain 
View,  California,  estiaates  that  transferring  100  MB  of  data 
to  CD  ROM  from  tape  or  floppies  could  cost  nearly  $20,000. 
"Copies  of  the  Master  disk  cost  $25  each  for  100  or  aore,  or 
$10  each  for  1000  and  up. " (Cuanings ,  1987,  p.  232)  So  in 
large  quantities  the  CD-ROM  is  an  econoaical  medium,  but  for 
small  production  runs  such  as  a  single  1:50,000  aap  data  set 
for  one  operation  the  cost  would  be  staggering. 

One  solution  would  be  to  develop  the  disks  on  a 
large  scale  and  store  thea  for  distribution  as  needed,  just 
as  paper  maps  are  today.  But  that  would  cause  distribution 
probleas.  Prepositioning  disks  from  a  large  production  run 
aight  work,  but  there  are  probleas  inherent  in  that  system 


also.  Other  problems  with  CD-ROM  are  that  it  is  "Read  Only 
Meaory"  and  cannot  be  written  on  by  the  users,  and  the 
access  times  are  slow  when  compared  to  hard  drives. 

c.  Write  Once-  Read  Many  (WORM)  Drive 

WORM  (Write  Once  Read  Many  times)  offers  an 
acceptable  solution.  A  WORM  drive  is  capable  of  storing 
between  120  and  200  megabytes  depending  on  the  manufacturer. 
"The  claimed  life  for  WORM  optical  cartridges  is  10  years, 
versus  3  years  for  magnetic  media.  As  a  result,  you  can 
expect  the  data  on  a  WORM  cartridge  to  endure  longer  than 
the  expected  life  of  the  host  computer ( Rosch,  "WORMs  for 
Mass  Storage",  1987,  pp.  135-136)  A  WORM  disk  presently 
costs  $125  and  up  for  single  sided  media,  and  up  to  $249  for 
double  sided  disks,  which  can  be  produced  as  required  on  any 
system  with  a  WORM  drive.11 

Either  the  WORM  or  CD-ROM  drives  would  offer 
adequate  support  of  the  very  large  databases  required  to 
support  a  digital  mapping  system.  However,  the  WORM  offers 
the  capability  to  write  to  the  disk  which  the  CD-ROM  does 
not.  This  would  give  the  TDMS  the  ability  to  construct  its 
composite  maps  files  on  disk,  and  would  give  the  user  units 
the  ability  to  create  overlay  files  as  they  required. 

d.  Optical  Memory  (Laser)  Card 

An  even  smaller  more  compact  media  alternative 
for  smaller  map  data  areas  is  the  Optical  Memory  Card.  An 
Optical  Memory  Card  is: 

A  card  based  upon  a  unique  optical  recording  medium 
similar  to  that  used  in  today’s  optical  disks.  But, 
unlike  optical  disks,  the  optical  memory  card  is  a 
convenient  size  and  shape  (similar  to  a  typical  credit 
card)  and  is  very  inexpensive. 


One  such  optical  memory  card,  the  Drexler  LaserCard™ 
can  store  up  to  16  million  bits  of  updatable  but 
nonerasable  digital  data  at  a  price  well  under  $5  per 
card. (Barnes  and  Sukernick,  1986,  p.  5) 


11 .  Figures  derived  from  "WORMs:  Summary  of  Features" 
Table  in  Rosch,  "WORMs  for  Mass  Storage",  p.  142. 
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Several  data  sizes  are  available  as  need 
requires.  There  are  primarily  three  different  cards:  a  625 
KB  card  with  one  16mm  strip  of  recording  media  for  saall 
jobs;  a  2.2  MB  card  with  two  35aa  strips  of  media  on  one 
side;  and  then  there  is  the  8.8  -  10  MB  card  that  has  all 
the  surface  of  both  sides  covered  with  aedia.  Bach  of  these 
cards  would  provide  adequate  storage  for  soae  particular  aap 
data  sets  that  they  would  be  used  to  transport. 

The  cards  are  produced  at  the  Drexler  plant  (the 
sole  source  of  the  cards)  using  photolithography  to  very 
quickly  reproduce  literally  thousands  of  identical  optical 
aeaory  cards.  These  cards  can  then  be  updated  or  blank 
cards  can  be  written  at  a  user  site  by  reader/writer  units 
which  are  attached  to  the  host  (micro  or  mini)  computer  by 
means  of  a  SCSI  (Small  Computer  Standard  Interface)  or  RS- 
232c  (serial)  interface.  "A  moderate-speed  laser  recording 
system  operating  at  100  kilobits/second  could  produce  one  2- 
megabyte  LaserCard™  on-demand  in  less  than  three  minutes... 
and  these  same  optical  memory  cards  could  later  have  data 
added  to  them  by  low-speed  laser  recording  (10 
kilobits/second) . "(Barnes  and  Sukernick,  1986,  p.  5)  These 
cards  could  be  used,  customized  and  updated  as  required  at 
the  local  unit  level,  using  a  read/write  unit  internal  to 
(the  Nipponcoinco  LC-301  reader/writer  weighs  5.5  lbs  and  is 
about  the  size  of  a  full-height  disk  drive)12,  or  attached 
to  the  microcomputer  that  provides  the  map  display.  There 
is  even  an  existing  security  system  that  can  be  implemented 
in  each  optical  memory  card  that  virtually  assures  that  the 
data  could  not  be  used  by  unauthorized  personnel. 

C.  MONITOR  (DISPLAY) 

We  determined  early  in  the  study  that  color  was  a 
necessity  to  provide  the  information  necessary  on  a  aap 

12 .  "Optical-Card  Reader  Uses  New  Technology",  PC  Week 
Magazine.  (March  31,  1987),  p.  22. 
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display.  While  the  Hercules  Monochrome  Graphics  Adapter 
provides  a  slight  advantage  in  resolution  over  the  color 
systems,  the  trade-off  was  well  worth  it  for  the  increase  in 
the  amount  of  information  represented,  and  the  ease  of 
understanding  it  afforded.  Therefore,  the  TOMS  prototype 
system  was  developed  using  an  Enhanced  Graphics  Adapter  (EGA 
card)  and  an  Enhanced  Color  Display  which  subscribe  to  the 
IBM  Enhanced  Graphics  Adapter  standard.  This  means  that  the 
card  will  display  16  colors  at  a  maximum  resolution  of  640  X 
350  pixels  per  screen .( Shneiderman ,  1987) 

We  found  that  EGA  is  just  barely  adequate  for  the  task 
at  hand,  and  an  order  of  magnitude  improvement  in  monitor 
resolution  would  heighten  the  map  display  greatly.  This 
would  allow  more  accurate  placement  of  the  symbols  on  the 
screen  to  improve  resolution  of  the  map.  It  should  also 
allow  a  larger  variety  of  colors  to  be  used  for  better 
distinguishing  between  symbols  and  conveying  information. 
With  a  greatly  improved  monitor  the  capability  variable 
display  resolution  could  improve  usability  of  the  system. 

1 •  Hercules  Monochrome  Graphics  Adapter  (Hercules 

Graphics ) 

"...the  Hercules  Graphics  Card,  a  monochrome 
graphics  adapter  that  displays  graphics  on  a  standard 
monochrome  monitor  at  a  resolution  of  720  dots  by  348 
lines. "(Alsop,  1986,  p.  141)  But  this  resolution  is  in  two 
colors,  background  and  foreground.  As  explained  in  the 
Schneiderman  text,  this  will  not  present  enough  usable 
information  quickly  enough  even  at  this  resolution.  Colors 
are  necessary  unless  each  symbol  can  be  represented  by  a 
distinctly  different  and  recognizable  shape.  To  be 
effective  in  monochrome  TDMS  would  need  much  improved 
resolution,  possibly  two  or  three  orders  of  magnitude 


improvement . 


Color  Graphics  Monitor  Adapter 


The  color  graphics  adapter  proved  to  be 
unsatisfactory.  In  alphanuaeric  aode  only  characters  nay  be 
displayed  in  one  of  16  colors  at  a  resolution  of  160-  by 
100-pixels.  The  all-points-addressable  (APA)  nodes  provided 
improvement,  however  the  limitations  were  too  strict. 


In  the  APA  graphics  aode,  there  are  two  resolutions 
available:  a  medium-resolution  color  graphics  node  (320 
PELs  by  200  rows)  and  a  high-resolution  black-and-white 
graphics  node  (640  PELs  by  200  rows).  In  medium- 
resolution  aode,  each  picture  elenent(PBL)  aay  have  one  of 
four  colors.  The  high-resolution  aode  is  available  only 
in  b lack-and-whi te ....( Internet ional  Business  Machines, 
1984,  p.  3) 


None  of  these  options  are  adequate  to  represent  the 
information  it  is  necessary  to  depict  on  a  aap  screen 
display.  Therefore,  CGA  was  not  ever  considered  as  an 
alternative  for  the  systea  display. 

3.  Enhanced  Graphics  Adapter  (EGA 


The  EGA  system  provides  a  vast  improvement  over  CGA 
with  16  colors  at  a  resolution  of  640  by  350,  almost 
watching  the  resolution  provided  by  the  Hercules  Graphics 
Adapter,  while  providing  the  colors  necessary. (Alsop,  1986, 
p.  142)  This  was  adopted  as  the  ainiaua  acceptable  display 
and  adapter  coabination  for  prototype  development  because 
BGA  was  coaaonly  available,  and  it  provides  the  capabilities 
necessary  to  aake  a  TOMS  usable. 

Of  the  16  available  colors  8  were  used  in  the 
prototype  of  the  aap  display,  which  are  clearly 
differentiable  as  representing  different  elevations. 

4 .  Professional  Graphics  Systea  (PGS) 

"The  IBM  Professional  Graphics  Systea  (PGS)  consists 
of  a  high-resolution  color  monitor  Batched  to  a  graphics- 
controller  board;  it  provides  flickerless  640-  by  480-pixel 
graphics  iaages  in  256-out  of  a  possible  4096-  simultaneous 


colors (Jadrnicek,  1985,  p.  355)  This  is  a  higher 
perforaance  display  which  is  also  aore  expensive  than  EGA. 

5 .  Multiscan  Monitors 

The  new  aultiscan  aonitors  (ie.  NEC  Multisync,  Sony 
Multiscan,  etc.)  have  the  capability  of  providing  better 
resolution  than  even  the  PGC  systea.  "The  aaxiaua 
resolution  claiaed  is  900  by  560,  coapared  to  NEC 
Multisync's  800  by  560  and  the  BGA  standard  of  640  by 
350 . " ( Wiswel 1 ,  Puglia,  and  Rose,  1987,  p.  136)  The 
aultiscan  aonitors  derive  an  iaproveaent  in  resolution  froa 
an  increased  capability  in  the  horizontal  scan  rate  of  the 
electron  gun,  and  in  increased  bandwidth  that  will  allow 
thea  to  read  the  output  adapters  up  to  that  speed.  The  best 
recognized  of  these  new  aonitors  is  the  NBC  Multisync  which 
has  a  horizontal  scan  rate  of  35MHz,  and  can  therefore 
synchronize  with  the  14  MHz  of  CGA,  16  MHz  of  BGA,  and  the 
30.48MHz  of  the  PGC  adapters  output  signal. 

However,  it  has  been  in  only  the  last  three  or  four 
aonths  that  adapter  cards  that  can  produce  the  display 
resolution  to  challenge  the  aultiscan  aonitors  have  coae 
onto  the  aarket  (ie.  the  NBC  GB1  and  the  Genoa  SuperBGA 
adapter  cards).  These  adapters  were  not  available  the 
researchers  and  therefore  consent  on  their  ability  to 
display  TOMS  satisfactorily  cannot  be  Bade.  The  NBC 
Multisync  with  the  proper  adapter  card  could  produce  seventy 
one  kiloaeter  grid  squares  using  four  by  four  pixel 
characters.  This  is  still  far  short  of  what  is  felt  to  be 
the  optiaua  nap  display. 

6.  Graphic  Workstations 

We  acknowledge  that  the  resolution  and  colors 
available  to  the  ainicoaputer ’ s  graphic  workstation  are 
adequate  to  produce  the  results  that  are  desired  for  a  TOMS. 
In  fact  the  coaputing  power  of  the  ainicoaputer  is  desirable 
if  not  a  necessity,  however,  our  thesis  is  that  a  coaputer 


can  produce  adequate  Bap  display's  to  sake  then  a  usable 
tool  to  a  tactical  field  coaaander.  The  ainicoaputer  is  not 
the  answer  because  of  the  rough  handling  and  liaited 
environaental  support  that  is  characteristic  of  field 
operations . 

7 .  Video  Co-processors 

The  recent  developaent  of  adapter  cards  and  software 
to  support  the  new  dedicated  "video  co-processors"  of  Intel 
and  Texas  Instruaents  will  further  the  cause  of  display 
resolution.  In  fact,  the  Intel  82786  graphic  processor  "... 
can  display  1024  colors  siaultaneously  and  supports 
resolutions  froa  640  by  480  pixels  by  8  bits,  ...up  to  a 
aaxiaua  of  4096  by  4096  pixels  by  1  bit ." (Nichols ,  1987,  p. 
135)  The  adapter  cards  built  around  this  chip  will  provide 
auch  faster  screen  draw  and  re-draw,  better  resolution,  and 
aore  colors  to  enhance  a  TDMS.  Unfortunately,  this 
technology  is  not  readily  available  today.  But  it  will  be 
by  the  tiae  a  fully  developed  TDMS  could  be  fielded. 

D.  CONCLUSION 

The  problea  of  inadequate  data  storage  space  on  a 
aicrocoaputer  systea  for  the  TDMS  a&p  database  can  be  solved 
with  the  optical  storage  technology  available  today.  A 
single  CD-ROM,  WORM  disk,  or  Laser  Card  provide  the 
advantages  of  treaendous  storage  space  (over  616  one 
kiloaeter  grids  on  a  laser  card),  saall  and  convenient  size, 
virtual  indestructibility,  and  current  availability.  This 
infant  industry  will  build  upon  these  every  day  as  this 
technology  aatures. 

The  iaproveaent  in  display  resolution  that  is  required 
to  aake  TDMS  a  true  productivity  tool  aay  be  derived  through 
three  aeans:  (1)  larger  screens,  (2)  saaller  pixels  which 
allows  aore  on  the  screen,  and  (3)  higher  scan  rates.  This 
technology  is  progressing  as  is  indicated  by  the  advances 
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over  the  last  three  years  fro*  CGA,  to  EGA,  to  PGA,  and  now 
into  the  multiscan  Monitors  and  their  graphic  adapters. 

Yet  according  to  Rich  Bader,  co-founder  of  Intel 
Corporation's  Personal  Computer  Enhancement  Operation; 
"What’s  happening  is  that  you  want  more  pixels  on  the  screen 
in  order  to  get  better  resolution.  Clearly,  the  more  pixels 
you  add,  the  more  CPU  cycles  it  ordinarily  takes  to  keep  the 
screen  ref reshed ."( Knorr ,  1987,  p.  222)  This  indicates  that 
more  machine  is  required  to  support  improved  graphics.  The 
present  microcomputer  technology  does  furnish  the  capability 
to  improve  over  the  next  few  years,  because  of  the 
relatively  new  80386  CPU,  new  graphics  co-processors,  32-bit 
compilers  and  assemblers. 
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VI.  EVALUATION 


The  standard  tactical  military  map  is  a  two  dimensional 
representation  of  real  terrain.  The  1:50,000  map,  most 
common  in  planning  an  exercise  or  mission,  measures  40 
inches  by  52  inches,  and  weighs  four  ounces.  This  allows  a 
standard  representation  of  approximately  2700  square 
kilometers.  It  displays  dozens  of  features  and  symbols  in 
nine  colors  on  a  high  grade  sheet  of  paper  with  a  resolution 
of  12,000  dots  per  inch.  Without  updating  and  reprinting  of 
the  map  by  DMA  its  representation  cannot  be  changed.  Any 
system  for  mapping  must  be  compared  to  this  standard. 


A.  DATA 


In  the  data  area  of  study,  there  were  the  following 


conclusions 


1 .  Feasibility 


The  TTADB  is  adequate  and  will  be  available  from  DMA 
for  use  in  a  digitized  mapping  system  of  world-wide  scope. 
The  lack  of  text  data  puts  the  digitized  database  at  a 
disadvantage  to  the  paper  map.  Unless  a  method  for 
providing  the  names  of  rivers  and  towns,  etc.  in  the 
database  is  developed,  it  cannot  fully  replace  paper. 


2 .  Limitations 


The  TTADB  stores  data  in  199  bit  records.  There  are 


6561  records  per  square  kilometer.  This  means  a  1:50,000 
map  contains  approximately  438  megabytes  of  information. 

This  amount  has  been  greatly  reduced  in  our  prototype  system 
without  sacrificing  accuracy  to  an  unacceptable  point,  but 
the  database  will  still  be  extremely  large. 

Any  system  designed  will  be  vulnerable  to  its  data 
source.  The  display  is  capable  of  creating  all  of  the 


symbols  required  by  TTADB  and  aore,  but  only  that 
information  contained  in  TTADB  can  be  displayed.  Any 
failure  of  the  TTADB  or  the  DMA  in  their  production  of  the 
TTADB  will  result  in  a  feilure  of  the  system.  A 
microcomputer  mapping  system  can  only  compete  with  paper 
maps  if  TTADB  contains  the  same  useful  data,  or  more,  as  its 
paper  counterpart. 

B.  SOFTWARE 

In  reviewing  the  current,  related  DOD  initiatives  and 
with  the  development  of  the  prototype,  there  were  the 
following  conclusions. 

1 •  Feasibi 1 itv 

Both  the  prototype  and  the  MicroDBM  programs 
indicated  a  digitized  mapping  system  could  produce 
traditional  two  dimensional  map  displays,  but  also  map 
formats  outside  the  range  of  paper  maps,  e.g.  three 
dimensional  and  tinted  slope  maps. 

2 .  Limitations 

Scanning  over  large  sections  of  a  map  and  large 
search/sorts  may  be  unacceptably  slow.  The  production  of 
field  deployable  systems  will  require  a  higher  performance 
machine  or  more  sophisticated  algorithms. 


C.  HARDWARE 

Conclusions  as  to  hardware  are  limited  by  the  hardware 
available  to  the  researchers.  Performance  of  better 
equipment  is  offered  as  mitigation  only. 

1 .  Feasibility 

Both  the  prototype  and  the  MicroDem  programs 
indicated  that  the  basic  requirements  for  a  digitized 
mapping  system  could  be  met  with  commonly  available 
hardware . 
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2 .  Limitations 

The  micro  computer  used  to  develop  the  digital 
mapping  system  prototype  (an  IBM  AT  compatible)  was  21 
inches  wide,  16  1/2  inches  deep,  and  6  1/2  inches  high.  It 
weighed  60  lbs  including  the  keyboard  and  the  monitor  which 
was  15  inches  wide,  14  1/2  inches  deep,  and  11  1/2  inches 
high.  This  may  be  unacceptable  for  field  use  since  its 
superiority  to  a  four  ounce  paper  map  is  as  yet  unproven. 
Currently  vendors  are  creating  systems  which  are  smaller  and 
may  be  equally  capable  and  more  environmentally  acceptable. 

An  EGA  system  is  capable  of  representing  16  colors 
at  one  time,  in  a  picture  7  inches  by  10  inches.  This 
allowed  a  representation  screen  of  only  five  square 
kilometers  in  the  prototype.  While  a  maximum  of  560  square 
kilometers  are  possible,  the  practical  limit  appears  to  be 
less  than  one  hundred  with  this  equipment.  Monitors  are 
currently  available  for  microcomputers  with  greater  screen 
densities,  more  colors  and  larger  screens. 

As  previously  noted,  data  storage  and  processor 
speed  were  considered  to  be  limiting  factors  to  system 
performance.  It  was  felt  that  the  80286  processor  and  the 
disk  technology  used  by  the  researchers  may  be  only 
marginally  adequate  for  the  demands  of  an  operational 
system.  The  80386  processor  and  developing  storage 
technology  may  eliminate  this  as  an  issue. 


D.  CONCLUSION 

The  utilization  of  digitized  maps  by  ground  tactical 
units  is  technologically  feasible.  The  microcomputers  used 
were  considered  to  be  marginally  adequate  for  the  task, 
given  their  limitations  of  processor  speed,  storage,  and 
display  capability.  Currently  available  advances  in 
microcomputer  hardware  should  reduce  these  limitations. 
Accordingly,  the  implementation  of  a  microcomputer  mapping 
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systen  is  considered  to  be  viable  with  current  technology. 
It  is  recognized  that  the  computer  cannot  replace  the  paper 
nap.  However,  it  can  be  a  valuable  tool  for  both  analysis 
and  the  high  speed  extraction  of  data. 
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APPENDIX  A 

TERRANAL:  MICROCOMPUTER  TERRAIN  MAPPING  PACKAGE 


(The  TERRANAL  description  is  extracted  from  a  paper  by  Major 
Peter  L.  Guth  (USAR)  submitted  for  March  1986  meeting, 
American  Congress  on  Surveying  and  Mapping.) 

The  TERRANAL  program  requires  the  following:  an  MS-DOS 
computer  with  at  least  256K  of  memory,  one  double  sided  disk 
drive,  and  a  graphics  card  and  monitor.  Optimal  execution 
requires  either  a  hard  disk,  or  an  additional  180K  of  memory 
to  place  a  complete  data  set  in  memory.  Dot  matrix  printers 
provide  hard  copy  output  using  the  DOS  screen  dump  facility, 
and  IBM  or  Epson  printers  support  greater  resolution  on 
certain  functions. 

TERRANAL  is  user-friendly,  menu-driven,  and  error- 
trapped,  with  optional  help  screens.  TERRANAL  accepts  two 
coordinate  systems  for  describing  location:  latitude  and 
longitude,  and  UTM.  The  UTM  grid  is  present,  if 
inconspicuous,  on  most  USGS  maps,  and  easier  to  use  than 
minutes  and  seconds  for  latitude  and  longitude.  Although 
UTM  coordinates  represent  the  primary  reference  for  program 
users,  we  retain  our  data  base  in  latitude-longitude  for  the 
following  reasons:  (1)  we  want  to  remain  as  close  to  the 
standard  data  DMA  base  as  possible;  (2)  we  can  avoid  the 
problems  of  grid  zone  boundaries  in  the  data  set  and  not 
provide  duplicate  data  sets  along  the  boundaries;  and  (3)  we 
prefer  the  theoretical  basis  of  interpolating  between  the 
DMA  values  rather  than  interpolation  between  a  UTM  data  set 
that  has  already  been  interpolated.  Thus  we  perform  the  UTM 
to  latitude-longitude  conversion  within  the  TERRANAL 
program,  but  only  for  the  end  points,  and  then  use  a  linear 
interpolation  within  the  data  array.  This  assumes  a  flat 
earth  over  that  portion  of  the  data  set  in  use,  which 
introduces  insignificant  error.  From  one  end  of  a  15  minute 


map  sheet  to  another,  data  spacing  varies  by  a  half  meter, 
which  is  negligible  considering  the  accuracy  and  resolution 
of  the  data. 

The  TERRANAL  program  currently  performs  the  following 
f  unct ions : 


--  Oblique  3D  views.  The  computer  will  draw  an  oblique 
block  view,  looking  in  any  desired  direction. 

--  Line  of  sight  profiles.  The  computer  will  draw  a 
topographic  profile  between  any  two  points,  and 
determine  inter -visibility. 

Cross  section  profiles.  On  IBM  or  Epson  dot  matrix 
printers,  the  program  can  draw  topographic  profiles  at 
any  desired  scale  and  vertical  exaggeration. 

Contour  maps.  The  computer  will  plot  contour  maps.  For 
military  purposes,  the  program  can  superimpose  masked 
and  visible  locations  for  an  observer  at  an  arbitrary 
point. 

Perspective  31)  views.  The  second  type  of  three 
dimensional  view  shows  a  camera-like  perspective  of  a 
wedge-shaped  piece  of  terrain. 

Tinted  elevation  maps.  Using  seven  elevation  categories 
which  the  user  can  vary,  the  computer  will  draw  tinted 
elevation  maps.  The  size  of  regions  allows  color 
patterns  to  give  seven  categories  with  only  four  colors. 

Slope  maps.  The  user  can  select  the  method  of  slope 
calculation  and  boundaries  for  the  four  categories,  and 
get  a  map  of  slopes  within  the  area.  Rapid  slope 
changes  allows  only  solid  color  categories. 

Elevation  histograms.  The  computer  can  rapidly  compute 
the  distribution  of  elevations  within  the  data  set,  and 
statistics  of  the  distribution. 

We  are  developing  additional  capabilities.  Because  of 
the  modular,  structured  nature  of  the  Pascal  source 
code,  a  user  could  easily  incorporate  desired 
improvements . 

—  Vertical  exaggeration  can  be  selected  for  the  line  of 
sight,  oblique,  and  perspective  views.  Long  lines 
require  vertical  exaggeration  to  preclude  flat  profiles. 
The  computer  will  automatically  suggest  the  largest 
vertical  exaggeration  that  will  fit  on  the  screen. 

The  oblique  and  perspective  views  are  drawn  as  a  series 
of  profiles,  progressing  from  rear  to  front.  An  area 
fill  routine  erases  the  hidden  lines,  precluding  the 
calculation  of  hidden  line. 


TERRANAL  serves  as  a  tool  for  the  analyst,  who  must 
clearly  understand  the  limitations  of  the  system.  The  data 
resolution  (60-90  meters)  means  that  the  data  accurately 
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reflects  the  general  features  of  the  topography,  but  will 
not  depict  micro-relief.  The  DTED  accuracy  Bust  also  be 
considered;  our  experience  indicates  that  the  accuracy 
faithfully  portrays  the  general  trends  of  the  topography. 
Finally,  vegetation  and  other  features  data  are  generally 
not  available  in  digital  format.  Even  with  its  data 
limitations,  TERRANAL  offers  powerful  digital  terrain 
mapping  capabilities  on  today's  most  widely  available 
microcomputers . 

For  more  information  contact: 


ience 


Capt.  Gene  Ressler  USArmy 
Dept.  Geography  A  Computer  Sci< 
United  States  Military  Academy 
West  Point.  NY  10996-1695 
Comm:  (914)  938-4866/3128 
AVON:  688-4866/3128 
DDN/ARPANet :  ResslerWWest Point . ARP A 


APPENDIX  B 


MICRODEM:  MICROCOMPUTER  PROGRAM  FOR  MANIPULATING  LARGE 

DIGITAL  TERRAIN  MODELS 

(The  MicroDEM  narrative  was  edited  from  documentation 
included  with  the  program  by  Peter  L.  Guth,  Eugene  K. 
Ressler,  and  Todd  S.  Bacastow.  ) 

Two  serious  impediments  have  limited  the  widespread  use 
of  digital  cartography.  First,  the  effort  required  to 
digitize  topography  limits  application  of  well  known 
principles.  Second,  existing  programs  require  a  high  degree 
of  computer  sophistication  and  access  to  relatively  large 
computers.  We  have  developed  a  program,  MicroDEM  (for 
Microcomputer  Digital  Elevation  Modelling),  which  addresses 
both  impediments.  MicroDEM  runs  on  MS-DOS  microcomputers 
(IBM  PC  and  compatibles)  and  manipulates  digital  elevation 
models  available  from  the  U.S.  Geological  Survey.  Digital 
data  covers  the  entire  United  States;  similar  data  might  be 
available  for  other  regions  of  the  world.  Thus  we  have  an 
easy  to  use  program  running  on  the  most  popular  and  widely 
used  microcomputer,  using  readily  available  digital  data. 

MicroDEM  requires  an  MS-DOS  computer  with  a  graphics 
monitor  conforming  to  the  IBM  Color  Graphics  Adapter  (CGA) 
standard.  (It  will  run  on,  but  not  yet  use  the  greater 
capabilities  of  the  newer  Enhanced  Graphics  Adapter  (EGA), 
and  will  run  on  some  monochrome  graphics  monitors).  Hard 
copy  output  can  be  generated  on  any  device  that  implements 
the  MS-DOS  graphics  screen  dump  utility.  The  program  makes 
special  use  of  Epson  and  IBM  dot  matrix  printers  to  produce 
high  resolution  images. 

The  source  code  for  MicroDEM  (currently  about  6500 
lines)  is  in  Turbo  Pascal  (Borland  International,  1985).  We 
chose  this  language  because  it  has  become  a  de  facto 
standard:  the  compiler  is  inexpensive,  it  provides  an 


excellent  development  environment,  it  compiles  rapidly  and 
produces  good  executable  code.  Further,  Pascal  is 
transportable,  and  as  a  structured  language  it  provides  for 
easy  program  maintenance.  As  proof  of  these  advantages,  we 
have  a  version  of  the  program  running  on  an  enhanced  Apple 
II+.  Because  of  the  modularity,  the  program  can  be  adapted 
to  use  digital  data  for  a  wide  variety  of  functions. 

MicroDEM  uses  the  Digital  Terrain  Elevation  Data  (DTED) 
Level  I  produced  by  the  Defense  Happing  Agency.  MicroDEM 
can  be  modified  to  work  with  other  digital  data  bases,  but 
none  currently  provide  as  widespread  coverage.  MicroDEM 
uses  only  digital  elevation  data;  we  have  not  yet  expanded 
it  to  use  digital  feature  data. 

The  MicroDEM  program  is  user-friendly  and  error-trapped, 
so  that  the  user  knows  what  the  computer  wants  and  incorrect 
responses  are  handled  predictably.  The  main  menu  offers  the 
choice  of  the  options  available.  In  addition,  the  user  can 
change  the  environment  defaults,  store  and  restore  images 
produced  by  the  program,  or  switch  to  a  new  area. 

The  MicroDEM  program  will  currently  produce  the 
following: 

Color  tinted  elevation  maps,  with  seven  user  defined 
categories,  at  any  desired  scale; 

Slope  maps,  with  four  user  defined  categories,  at 
any  desired  scale; 

Contour  maps,  at  any  desired  scale  and  contour 
interval,  and  masked  area  plots  showing  terrain 
hidden  from  an  observer; 

Topographic  profiles  between  any  two  desired  points, 
at  any  desired  scale  and  vertical  exaggeration; 

Oblique  three  dimensional  views  with  any  desired 
orientation; 

Datum  shifts  and  coordinate  transformations  between 
UTM  and  geographic. 

MicroDEM  provides  a  flexible  means  to  manipulate  digital 


The  prograa  runs  on  low-cost,  industry  standard  MS-DOS 
■icrocoaputers ,  putting  digital  cartography  within  the  reach 
of  alaost  any  potential  user. 


Contact : 

Dr.  Peter  Guth  (Major  USAR) 
Dept.  GeoScience 
University  of  Nevada 
Las  Vegas.  NV  89154 
Cobb:  (702)  739-3262 


APPENDIX  C 

AMPHIBIOUS  OBJECTIVE  AREA  LAND  MANAGEMENT  SYSTEM 


(The  AOALMS  Site  Data  Users  Guide,  documentation  prepared 
for  Naval  Civil  Engineering  Laboratory  under  contract  no. 

N00 123-84-D-O 152 ,  was  used  to  derive  this  explanation.) 

1 •  System  Description 

The  mission  of  the  AOALMS  is  to  enable  U.S.  Marine  Corps 
(USMC)  personnel  to  rapidly  plan  horizontal  construction 
projects  in  the  Amphibious  Objective  Area  (AOA).  The  system 
consists  of  a  microcomputer  and  software  programs  that  aid 
USMC  users  in  (1)  rapidly  examining  site  conditions  and 
identifying  promising  locations  for  AOA  facilities,  (2) 
designing  the  facilities  and  calculating  earthwork 
requirements,  (3)  determining  the  numbers  and  types  of 
construction  equipment  needed  to  achieve  facility  completion 
dates,  and  (4)  scheduling  the  entire  AOA  horizontal 
construction  effort  to  ensure  optimum  usage  of  construction 
equipment.  The  AOALMS  is  used  by  the  Landing  Force 
Commander  and  USMC  Engineer  Support  Battalion  for  the 
planning  and  construction  of  facilities  worldwide.  The 
planning  is  accomplished  prior  to  departure  (mount-out), 
aboard  ship,  and  after  arrival  in  the  AOA. 

The  AOALMS  is  currently  designed  for  operation  on  IBM  XT 
and  AT  microcomputers  (essentially,  IBM  Personal  Computers 
(PC’s)  with  hard  disk  drives).  The  IBM  XT  consists  of  a 
monitor,  one  5-1/4-inch  floppy  disk  drive,  one  hard  disk 
drive,  and  a  keyboard.  The  IBM  XT  uses  an  Epson  FX-100  dot¬ 
matrix  printer  to  print  reports  and  to  dump  screen  graphics. 
One  program  in  the  AOALMS  requires  the  use  of  a  large 
Gigatek  monitor  to  provide  high-resolution  graphics. 

Most  AOALMS  software  has  been  programmed  in  Janus  Ada,  a 
microcomputer  version  of  the  Ada  programming  language.  The 
program  that  uses  the  Gigatek  monitor  is  coded  in  Basic. 

The  AOALMS  has  been  developed  using  the  PC-DOS  operating 


systea,  the  standard  operating  systea  for  the  IBM  PC  faaily 
of  aicrocoaputers . 

The  prograas  consist  of  two  independent  subsysteas:  the 
Site  Selection  Subsystea  and  the  Site  Evaluation  Subsystea. 
Within  the  Site  Evaluation  Subsystea  are  four  aodules:  (1) 
Site  Data  Module,  (2)  Facility  Module,  (3)  Equipment  Module, 
and  (4)  Schedule  Module. 

The  subsysteas  and  aodules  perfora  specific  operations 
within  the  AOALMS.  These  operations  are  suaaarized  in  table 
below. 


Subsystea  and  Module  Operations 


Subsystea/Module 
Site  Select.  Subsystea 


Site  Eval.  Subsystea 


Site  Data  Module 


Operation 

Displays  site  conditions  for  areas 
up  to  100  square  kiloaeters, 
permitting  user  to  select  promising 
sites  for  AOA  facilities.  Uses 
custoa  aonitor  to  provide  clear 
graphics.  It  is  the  only  AOALMS 
program  coded  in  Basic. 

Evaluates  required  earthwork, 
equipment,  and  tiae  necessary  to 
coaplete  the  facility. 

Provides  inforaation  on  site 
conditions  to  be  used  in 
calculations  in  other  aodules. 


Facility  Module 


Equipaent  Module 


Scheduling  Module 


Designs  facility  and  calculates 
earthwork  requirements .  In  its 
final  configuration,  the  module  will 
provide  calculations  for 
standardized  facilities.  Current 
version  handles  only  one  type  of 
facility,  the  Vertical/Short  Takeoff 
and  Landing  (VSTOL)  Airbase. 

Uses  standard  earthaoving 
equations  to  calculate 
productivity  of  USMC  and  Naval 
Construction  Force  equipaent 
under  the  specific  conditions  at 
the  site. 

Allows  user  to  schedule  theearthwork 
construction  effort  for  all 
facilities  at  the  AOA  by  correlating 
the  results  of  calculations 

Serforaed  by  the  Facility  and 
quipaent  Modules. 


2 .  System  Operation 


a.  Site  Selection  Subsystem 

The  Site  Selection  Subsystem  is  a  stand-alone 
program  that  displays  site  conditions  for  areas  up  to  100 
square  kilometers,  permitting  you  to  select  promising  sites 
for  AOA  facilities.  The  program  uses  two  monitors.  The 
smaller  monitor  is  used  to  enter  data  to  the  computer  in 
response  to  displayed  questions.  The  larger  monitor 
presents  a  perspective  display  of  a  100-square-kilometer 
AOA.  The  approximate  run  time  for  the  program  is  30 
minutes . 

You  are  asked  to  select  the  facility  type  to  be 
evaluated.  The  only  facility  handled  by  the  current  program 
is  the  VSTOL  Airbase.  All  other  user  choices  will  be 
rejected.  You  are  asked  for  the  distance  from  the  facility 
to  the  nearest  quarry  with  subgrade  material.  You  are  also 
requested  to  select  the  type  of  military  unit  performing  the 
construction  project  (e.g.,  Naval  Mobile  Construction 
Battalion).  The  program  then  asks  you  to  select  the  desired 
view  of  the  AOA.  The  program  provides  recommended  view 
selections  to  help  you  make  your  decisions.  You  select  the 
desired  direction  of  view,  the  altitude,  the  distance  from 
the  AOA,  and  topography  exaggeration,  if  any.  If  you 
desire,  you  can  position  a  VSTOL  Airbase  on  the  AOA  by 
specifying  a  rotation  angle  and  the  location  coordinates  for 
the  facility. 

A  fullcolor  perspective  display  then  appears  on  the 
larger  monitor  with  the  specified  view  of  the  AOA  and  the 
VSTOL  Airbase.  The  view  consists  of  several  grids,  each  of 
which  represents  a  200-  by  200-meter  area.  The  grids  are 
colored  to  signify  the  relative  effort  required  to  build  the 
facility  at  that  location. 
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b.  Site  Evaluation  Subsystem 

The  Site  Evaluation  Subsystem  evaluates  the 
earthwork,  equipment,  and  time  required  to  complete  the 
facility.  This  program  is  used  after  a  preliminary 
assessment  of  various  sites  has  been  performed  with  the  Site 
Selection  Subsystem.  The  approximate  run  time  for  the  Site 
Evaluation  Subsystem  is  3  hours. 

A  menu  provides  you  with  a  list  of  the  four 
modules.  You  can  select  any  one.  The  Facility  Module 
designs  the  facility  and  calculates  earthwork  requirements. 
You  are  asked  for  the  type  of  facility.  In  its  final 
configuration,  the  module  will  provide  calculations  for  11 
standardized  facilities.  The  current  version  handles  only 
one  type  of  facility,  the  VSTOL  Airbase.  You  are  asked  to 
provide  the  facility  location  (easting  and  northing 
coordinates)  and  the  clockwise  rotation  angle  from  north. 

The  computer  performs  extensive  facility 
calculations  that  take  more  than  1  hour  to  complete.  When 
the  run  is  completed,  you  are  provided  with  a  facility  menu 
that  allows  you  to  examine  various  results  of  the  facility 
calculations.  You  can  list  earthwork  quantities, 
graphically  view  profile  cuts,  and/or  display  an  aerial  view 
of  the  facility. 

The  Equipment  Module  uses  standard  earthmoving 
equations  to  calculate  the  productivity  of  USMC  and  Naval 
Construction  Force  equipment  under  the  specific  conditions 
at  the  site.  This  module  has  a  run  time  of  about  1  minute. 
You  cannot  display  the  output  from  this  module. 

The  Scheduling  Module  allows  you  to  schedule  the 
earthwork  construction  effort  for  all  facilities  at  the  AOA 
by  correlating  the  results  of  calculations  performed  by  the 
Facility  and  Equipment  Modules.  From  the  scheduling  menu, 
select  Case  I.  You  are  asked  to  select  equipment  by 
function  or  type  and  to  provide  quantities  of  each.  After 
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you  have  supplied  this  information,  the  computer  will 
perform  all  scheduling  calculations  in  less  than  5  minutes. 

A  menu  is  displayed  enabling  you  to  view  the  scheduling 
results,  including  a  tabular  schedule,  a  Gantt  chart,  and  so 
on.  Return  to  the  scheduling  menu  and  select  Case  II.  You 
are  asked  to  select  equipment  by  function  or  type  and  to 
specify  facility  completion  times.  As  with  Case  I,  a  menu 
is  then  displayed  enabling  you  to  view  the  scheduling 
results . 

The  Site  Evaluation  Subsystem  has  other 
features.  One  of  them  is  the  Site  Data  Module.  If  you  call 
up  the  module  from  the  main  menu,  you  can  construct  a  new 
site  data  disk.  The  Site  Evaluation  Subsystem  requires  one 
site  data  disk  (360K)  for  each  1,000  by  1,000  -meter  area. 
One  to  four  disks  will  be  needed  to  perform  calculations  for 
a  VSTOL  Airbase  at  any  given  location.  The  Site  Selection 
Subsystem  requires  one  site  data  disk  for  a  10,000  by  10,000 
-meter  area.  For  the  purposes  of  the  AOALMS,  this  is 
considered  the  standard  size  for  an  AOA. 

Additional  details  are  available  through: 

Dr.  Carter  Ward 
Code  L64 

Naval  Civil  Engineering  Laboratory 
Port  Hueneme.  CA  93043 
Comm:  (8051  982-5021 
AVON:  360-5021 
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APPENDIX  D 
TTAPB  FORMAT 


(The  AOALMS  Site  Data  Users  Guide,  documentation  prepared 
for  Naval  Civil  Engineering  Laboratory  under  contract  no. 
N00 1 23 -84-D -0 152 ,  was  the  source  of  this  TTADB  data  format 
explanation . ) 


The  first  block  of  information  is  a  9  item  header  where 
each  item  is  binary  integer  and  right  justified  in  32  bit 
fields.  Each  item  contains  the  following: 


I  tern  1 
Item  2 
I  tern  3 
I  tern  4 
Item  5 
I  tern  6 
Item  7 
I  tern  8 
Item  9 


Southwest  Corner  Easting  (in  meters) 
Southwest  Corner  Northing  (in  meters) 

No.  of  Columns 
No.  of  Rows 

Interval  between  columns  (in  centimeters) 
Interval  between  rows  (in  centimeters) 

No.  of  Physical  blocks  per  column 
Grid  Zone 

Spheroid  Code  (1-8)  designated  as  follows: 


Clark  1880  =  1 
International  =  2 
Clarke  1866  =  3 
Bessel  =  4 
Evevest  =  5 
Walbeck  =  6 
Fischer  =  7 
WGS  72  =  8 


cf. 


The  remaining  blocks  contain  the  elevations  and 
corresponding  features.  The  first  32  bits  of  each  logical 
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block  contains  the  block  count.  The  next  16  bits  coni 
the  relative  count  from  the  Southwest  corner  easting. 
Therefore,  each  elevation  t#m  in  a  column  will  have  the  same 
easting  count.  The  next  16  bits  contain  the  starting 
relative  count  from  the  Southwest  corner  northing. 

Successive  elevation  items  in  a  block  have  an  implied 
relative  northing  value  which  is  1  more  than  the  previous 
value.  For  example,  if  the  starting  relative  northing  count 
for  the  block  is  0,  then  the  third  elevation  item  has  a 
relative  northing  count  of  2.  Assuming  a  row  interval  of 
12.5  meters,  then  the  third  elevation  item  is  25  meters 
north  of  the  SW  corner  northing. 


The  remaining  bits  in  a  block  contain  elevation  items.  Each 
elevation  item  consists  of  199  bits  where  the  first  16  bits 
contain  the  elevation  and  the  other  183  bits  contain  the 
associated  codes  for  the  features.  Each  elevation  item  is 
fully  detailed  in  an  attached  format  description.  Each 
logical  block  is  terminated  by  at  least  36  one  bits. 
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PROTOTYPE  FORT  LEWIS-YAKIMA  TRAINING  AREA* 
TACTICAL  TERRAIN  ANALYSIS  DATA  BASE  ( TTADB )  FORMAT 
FOR  1:50,000  SCALE  PRODUCTS 


Bit  #  of 

Data _ Element  pea  ianat ion 

Surface  Conf  imrat  i  on  Overlay 
Elevation  (a)  1  -  16  (16) 

Slope  (*)  17  -  20  <  4 ) 


va  lue  Represented 


Mo  Data 

0  -  3 

3-10 
10-20 
20  -  30 
30  -  45 
>45 

Naturally  and/or  culturally 
dissected  land  (0->4S) 
(Numerous  small  hillocks 
sand  dunes,  glacial  debris, 
landfills,  dumps,  etc.) 


Vegetation  Overlay 
Type  21  -  26 


Open  Water 


0  No  Data 

1  Agriculture  (dry  crops) 

2  Agriculture  (wetland  rice) 

3  Agriculture  (terraced  crop: 
both  wet  and  dry) 

4  Agriculture  (shifting  cult 

5  Brush  1 and/Scrub  (<5m.high, 
nearly  open  to  medium  sp) 

6  Brush  1 and/Scrub  (<Sa  high, 
medium  to  dense  spacing) 

7  Coniferous/Evergreen  Fores 

8  Deciduous  Forest 

9  Mixed  Forest 

10  Orchard/Plantation  (rubber, 
palm,  fruit,  etc.) 

11  Grassland,  Meadows,  Pasture 

12  Grassland  with  scattered 
Trees  some  scrub  Growth 

13  Forest  Clearings  (cutover 
areas,  burns,  etc.) 

14  Swamp (mangrove , cypress , etc > 

15  Marsh/Bog(peat ,  muskeg, 
etc  > 

16  Wetlands  (L.S.I.,  low- 
lying  wet  areas) 

17  v l ne y ar d/Hop-garden 

IS  Bamboo 

19  Bare  Ground 


17  Vineyard 
IS  Bamboo 
19  Bare  Gro 
20-22 

23  open  water 

24  Built-up  Areas 
25-29 

30-63  Not  Used 


note:  On  account  of  programming  time  limitations,  this  Fort 

Lewis-vakima  prototype  is  a  condensation  of  the  full  proposed 
Tactical  Terrain  Analysis  Data  Base.  Numerous  data  fields  have 
had  to  be  compressed,  omitted,  or  specifically  tailored  to  the 
Fort  Lew i s - Yak i ma  terrain  conditions  to  meet  these  limitations. 


M.vw 


Canopy  Closure(>)27  -  29 


0  Mo  Data 

1  0  -  2S 

2  25  -  SO 

3  50-75 

4  75  -  100 
5-7 


Tree  Height  (a)  30  -  33 


0 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10-15 


Stem  Diaaeter(a)  34  -  37  (4) 

(Note:  CCM  formula  uses  aetera 

and  these  ranges  were  selected 
because  they  best  correspond 
to  the  push-over  limits  of  the 
vehicles  for  which  we  compute 
CCM) 


No  Data 
0  -  2 

2-5 
5-10 
10-15 
15  -  20 
20  -  25 
25  -  30 
30  -  35 
>35 

Not  Used 

No  Data 
0 


stem  Spacing  (a)  38  -  41 


12  1-3 

13  3-5 

14  5-10 

15  >10 


No  Data 

0-4.0  (by  0.5) 

4- 5 

5- 6 

6- 8 
8-10 
10-15 
>15 


vegetat ion 


42  -  46 


Roughness  Factor 


10-31  Not  Used 


& 


Undergrowth 


47  -  48 


0  No  Data 

1  None 

2  Sparse 

3  Dense 


r’«|l 

I! 
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Tree  Crown  49  -  51  (3)  o  No  Data 

Diameter  (meters)  1-7  Hot  Used 

(Note:  Need  if  we  intend  to  do  t n t e r- » i s  l  b i 1 i t y  or 

I ine-of-sifht  products;  otherwise  will  remain  zeroed  out) 

Height  of  Lowest  52  -  54  (3)  0  No  Data 

Branch  (meters)  1-7  Not  Used 

(Note:  Same  as  above) 

Surface  Material  Overlay 

Type  55  -  60  (6)  0  Ho  Data 

1  GW  -  Gravel,  well  graded 

2  GP  -  Gravel,  poorly  graded 

3  GM  -  Gravel,  silty,  clayey 

4  GC  -  Gravel,  clayey 

5  sw  -  Sand,  well  graded 

6  SP  -  Sand,  poorly  graded 

7  SM  -  Sand,  silty 

8  SC  -  Sand ,  clayey 

9  ML  -  S i 1 t 

10  cl  -  Clays 

11  ol  -  organic  silts 

12  MH  -  Inorganic  silts 

13  ch  -  Pat  clays 

14  OH  -  Pat  organic  clays 

15  pt  -  organic  peat 

16  Snowf le Id/G lac ler 

17  Rock  outcrops 

18  Evaporite 
19-61 

62  open  water 

63  Not  evaluated  (built-up  a 
etc  > 

Qualifier  61  -  65  (5)  0  No  Data 

1  None 

2  Boulder  field 

3  Quarry,  mine,  diggings 

4  Bare  rock,  smooth 

5  Lava  flow 

6  Dunes 

7  Loose 

8  Karst 

9  Lathyri  tic 

10  Permafrost 

11  Frequent  stone  or  rock 
outcrops 

12  Dissected 

13  Netal/ore  slag  dump 

14  Tailings,  waste  pile 

15  Strip  mine 

16  Rugged  bedrock 
17-31 


State  of  the  66  -  69  (4)  o  no  Data 

Ground  1  Dry 

2  Approximately  50k  saturation 

3  wet  (saturated) 

4-14  0  -  1.0  (by  O. l--f ract ion  of 

soil  moisture  in  top  half 
meter  at  time  of  measurement 
or  CCM 


synthes i zat  ion  ) 


r 

& 

LjT 


Bit  *  Of 

Data  Element  Pea i gnat  ion 


l  S 


Bits  Cod*  Value  Represented 


Depth  of  Surface  70  -  71 

(2) 

0 

No  Data 

Material  (meters) 

l 

0-0.5 

2 

>  0.5 

Surface  Roughness  72  - 

7  5  (4  > 

0 

No  Data 

Factor  -  Medium  and 

1 

0 

Heavy  Tanks  (M-l  Abrams, 

2 

0 . 05 

M60 ,  and  T-72  Tanks,  etc) 

3 

0  .  1 

4 

0 . 2 

5 

0 . 3 

6 

0 . 4 

7 

0 . 5 

8 

0 . 6 

9 

0 . 7 

(Hote:  One  SR  table  will 

be 

10 

0.75 

needed  for  each  vehicle 

type 

1  1 

0 . 80 

for  which  a  CCM  map  is  to  be 

12 

0 . 85 

prepared ) 

13 

0 . 90 

14 

0 . 95 

1  5 

1 . 00 

Surface  Roughness  70  -  79 

(4) 

0 

No  Data 

Factor  -  Large  Wheeled 
vehicles  (M3S  Truck,  etc) 

1 

-15 

Not  Used 

Surface  Roughness  80  -  83 

(4) 

0 

No  Data 

Factor  Small  Wheeled 
Vehicles  (M151  Jeep,  etc) 

1 

-IS 

Not  Used 

Surface  Roughness  84  -  87 

(4) 

0 

No  Data 

Factor  -  Light  Tracked 
vehicles  <Mll3  ARC,  etc) 

1 

-15 

Not  used 

Surface  Roughness  88  -  91 

(4) 

0 

No  Data 

Factor  Foot  Troops 

1 

-15 

Hot  Used 

Depth  to  Bedrock  92  -  95 

<  4  ) 

0 

Mo  Data 

(meters) 

1 

-15 

Not  Used 

(Note:  Need  if  we  intent 

to  support 

penetration  or 

engineering 

studies;  otherwise 

will 

remain  seroed  out) 

IV.  surface  Drainage  Overlay 

Type  96  -  98 

<3> 

0 

No  Data 

1 

Stream  Channel 

(Dry  wash  or 

intermittent, 

e . g. ,  Arroyo  ) 

2 

Lakes,  Ponds, 

Reservo i r s 

3 

Stream  Channel 

(Perennial ) 

4 

Stream  Channel 

(Subject  to 

Tidal  fluctuations) 

5 

Trenched  stream/ I rr i gat i on 

Cana  1 /Cana  1 /Dra i nag*  Ditch 

6 

Off-Route  Ford 

(Entrance  and 

Exit  points  connected) 

7 

Dam/Lock 

Gap  width  99  -  101  (3) 

0 

No  Data 

(Bank  to  Bank  (m)) 

1 

<  4.5 

2 

4.5  -  18 

3 

18  -  50 

4 

50  -  100 

5 

100  -  142 

e 

>  142 

Bits. 


Bit  •  of 

Data  Element  Dm  mat  ion 


Cod*  value  Represented 


Transportation  Overlay 
Type  123  -  126  (4) 


0  No  Data 

1  Bridge  -  Road 

2  Bridge  -  Railroad 

3  Tunnel  -  Road 

4  Tunnel  -  Railroad 

5  Dual  Lane/Divided  Highway/ 
Expressway 

6  Highway/Road 

7  Railroad 

8  Airfield 

9  Inland  Waterway 

10  Lock 
11-15 


Condition 


127  -  129  <  3 )  0 


No  Data 


Operational 

(Note:  Need  part  of  this  field  2 

now,  will  need  the  rest  if  we  3 

intend  to  support  air  operations  4 
or  on-route  t  r  a  f  f  i  c  a  b  i  1  1 1  y  5 

studies)  6 


Qua  1  1  f  1  e  r 


130  -  132 


(3) 


(Note:  Now  do  all  except  the 

grade  in  excess  of  38  for 
ra  i  1  roads  ) 


Length(setert)  133  -  13B  (6) 


(Note:  For  this  Fort  Lew i s - 

vakiaa  prototype,  length  only 
refers  to  Bridges,  Tunnels, 
Airfields,  and  other 
transportation  types  leas  than 
100  aeters  long.  All  lengths 
greater  than  loo  aeters  are 
deterained  by  the  nuaber 
of  points  used  to  digitise  the  10-31 
length  of  the  feature  -  0.25  aa 
(approx,  o.oi  inches)  equals  12.5 
aeters  on  the  ground  at  1:50,000 
scale)  . 


O 

1 

2 

3 

4 

5 

6 

7 

0 

1 

2 

3 

4 

5 

6 

7 

8 
9 


Good 
Fa  i  r 

Poor/Deteriorated 

Daaaged 

Des t  royed 

Abandoned/Di  saint  led 
Under  construction 

No  Data 

Road  Constriction)  4  aeters 
Grade  in  excess:  7Sfor  road 
or  3k  for  railroads 
Sharp  curve,  radlusOO  aeter 
Ferry  Site 
On  Route  Ford  Site 
Electrified  Line 


No  Data 
Unknown 
0-10 
10-20 
20  -  30 
30  -  40 
40  -  80 
60  -  80 
80  -  100 
>  100 
Not  Used 


Average  width  139  -  142  (4)  0  No  Data 

(aeters  >  1  Unknown 

2  0-3 

(Note:  For  this  Fort  Lewis-  3  3-4 

vakiaa  prototype,  width  refers  4  4-5 

to  any  transportation  type,  5  5-7 

except  Ra  i  1  roads , 1  ess  than  SO  6  7  -  10 

aeters  wide.  All  widths  7  10-20 

greater  than  50  aeters  are  8  20-50 

deterained  the  saae  as  lengths  9  >50 

greater  than  100  aeters  10  Not  Used 


Bit  0  of 

Data  Element  Designation  Bits 

Surface  143  -  146  <4> 

(Note:  Need  part  of  this  field 

now,  will  need  the  rest  if  we 
intend  to  support  on-route 
t r a f f i c ab  i  1  i  t y  studies) 


Highways  and/or  Roads: 

Type  147  -  149  ( 3 ) 


Ra i 1  roads  : 

Type  150  -  152  (3) 


Passing  tracks,  153  -  154  (4) 
sidings  S  yards 
< le t  e  r s  ) 


Tunnels: 

Height  (Meters)  155  -  157  <3) 


Br idges : 

Type  158  -  161  (4) 

(Note:  Need  if  we  intend  to 

support  engineer  or  on-route 
t r a f f i c a b i 1  i  t y  studies; 
otherwise  will  reiain  seroed 
out  ) 


Moveaent  162  -  164  (3) 


Code  value  Represented 

0  No  Data 

1  Paved 

2  Hard 

3  Loose/Gravel 

4  Unpaved 

5  Natural  Earth 

6  Grass 

7  Mac adaa/AS pha 1 t /B i t usi nous 

8  Concrete 

9  stone/aasonry/brick 
-IS  Not  Used 


0  No  Data 

1  All  weather 

2  Fair/Dry  Weather 

3  Cart  Tracks 

4  Trails 
5-7 


0  No  Data 

1  Noraal  Gauge,  single  track 

2  Noraal  Gauge,  dual  track 

3  Noraal  Gauge,  Multiple  (2 

or  aore)  tracks 

4  Narrow  Gauge,  single  track 

5  Narrow  Gauge,  aulti-track 

6  Broad  Gauge,  single  track 

7  Broad  Gauge,  aulti-track 

O  No  Data 

1  Passing  track  >=280 

2  Siding  >  =280 

3  Vard  >=280 


O  No  Data 

1  3-6 

2  6  -  B 

3  8-12 

4  >12 
5-7 


0  No  Data 

1  Truss 

2  G 1 rder 

3  Beaa 

4  Slab 

5  Arch 

6  Suspension 

7  Floating 

8  Cable  stayed 
B  Cant i lever 
-15  Not  used 

o  No  Data 
l  Fixed 
2-7  Not  used 


( Note :  Saae  as  above  ) 


B  1  t 
eaent 


*  of 

Desianat  i  on 


Overhead 

Clearance 


-  186  (2) 


No  Data 
Unknown 

Unlimited  clearance 
Possible  obstruction 
Military  traffic 


Horiiontil 

Clearance 


-  168  (2) 


No  Data 
Unknown 

Unlimited  Clearance 
Possible  obstruction 
•  i  1  i  tary  traf f  ic 


Underbr idee 
C  1  earance 


17  1  ( 3  > 


No  Data 

Unknown 

0-5 

5-10 

10-50 

>  50 

Not  used 


Bypass 

Cond i t i ons 
(Potent  ial 


within  2ka > 


No  Data 

easy 

Difficult 
laposs i ble 


Construct  ion 

Material 


-  176  <  3 ) 


No  Data 

Other 

wood 

Stone/aaionry/brick 

Stee  1 

Concrete 

Reinforced  concrete 
Prestressed  concrete 


Classification  ] 

(one-way  wheeled) 
(aetric  tons ) 


180  (4) 


0  No  Data 
1  50 

2-9 

10-15  Not  Used 


Classification  181 
(one-way  tracked) 
(■etric  tons ) 


-  184  (4)  O  No  Data 

1-7  0-60  (by  10) 
8  61  -  100 
9  >100 

10-15  Not  used 


Reliability  of  185  - 
Bridge  Classification 


No  Data 
Unknown 
Known 
Est  lasted 


Spans  (nuaber) 


-  190  (4) 


0  No  Data 

1  unknown 

2  1 

3  2 

4  3 

5-8  4  -  11  (by  2 ' s  > 
9  >  =  12 

10-15 


Value  Represented 


Bit  •  of 

Blount  Dog  i  gnat  ion 


Span  Length 
(aotort) 


191  -  193  (3) 


0  No  Data 
1  Unknown 
3  <25 

3  25-50 

4  50  -  100 

5  >100 
5-7 


ODs  tacloa  Ovorlai 


Typo  194  -  196  <3)  0 

1 

(Note:  Linear  obstacles  are  2 

defined  as  any  hinderance  to 
■ovesent  which  is  creator  than  3 

1.5  aeters  high,  has  a  45*  or 
greater  slope,  and  is  at  least 
250  aeters  long.  Areal  obstacles 
are  defined  as  any  area  which  is  4 
so  characterised  as  to  severely 
restrict,  stop,  or  otherwise  aake 
aoveaent  iapract leal .  This  over-  5 
lay  depicts  land  obstacles  only- 
user  is  referred  to  Surface 
Drainage  Overlay  for  hydrologic 
obstacles. ) 


No  Data 

Road  and  RR  cuts  and  fills 
Natural  linear  obstacles 
(escarpsents,  dikes,  cliffs, 
Walls  and/or  fences  soveient 
(hedgerows,  rock  and  wire 
fences  and  retaining  walls, 
etc  .  ) 

Other  san-iade  linear 
obstacles  (dikes,  aioats, 
eibanksents,  etc.) 

Military  obstacles 
(antitank  ditches,  airfield 
and/or  road  craters,  blown 
bridges,  debris  choked 
vslleys  and/or  towns, 

(■pact  sress,  Minefield, 
road-blocks,  trenches,  wire 
entangleaents .  etc.) 

Man-M*d*  areal 
obstac lea (Mi n i ng ) 
operat Iona --p i ts ,  quarries, 
atrip  Mines,  etc . --terraced 
hills  and/or  paddies  (wet 
and  dry)) 

Natural  area  obataclea 

(craters,  dissected  land, 
talua  piles,  depressions, 
sink  holes,  open  water, 
etc.) 


Height  (a) 


197  -  199  (3) 


No  Data 

<  1.5 
1.5-5 
5-10 
10  -  20 
20  -  35 
»  35 


The  Prototype  Fort  Lewis-Yakima  Training  Area  TTADB  matrixed 
foraat  ends  with  bit  199.  The  full  proposed  TTADB  includes  224 
bits  and  includes  additional  overlays  for: 

(1)  Aerial  Obstructions. 

(2)  Special  Features/Product  Synthesis  (custoser  related 
overlays/standardized  and  future  CCM,  Concealment,  etc. 
overlays) . 

(3)  Text  Data  (two)  -  for  such  information  as  bridge  tables, 
climatic  data,  hydrologic  flow  graphs,  names,  generalized 
descriptors,  etc.  On  account  of  the  limitations  mentioned  on 
page  1,  rather  than  carry  25  bits  packed  with  zeroes  at  the  end 
of  each  data  point,  it  was  decided  to  omit  these  fields  from  the 
Fort  Lewis-Yakima  Training  Area  TTADB. 
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APPENDIX  E 

RESULTS  OF  FIELD  REDUCTION  OF  THE 
TACTICAL  TERRAIN  ANALYSIS  DATA  BASE  ( TTADB )  FORMAT 

FIELDS  REMAINING 


Bit  *  Of 

Data  ilMtnt  Oeslgnat  ion  Bits  Coda  Value  Raoraaantad 
Transportation  Overlay 


Type 


123  -  126 


<4  ) 


0  No  Data 

1  Br  i  dge  -  Road 

2  Br idea  -  Railroad 

3  Tunne  1  -  Road 

4  Tunnel  -Rail  road 

5  Dual  Lana/D i v i dad  Highway/ 

Expressway 

6  Highway/Road 

7  Railroad 

8  Airfield 

9  Inland  Waterway 

10  Lock 


Qualifier  130 


Highways  /  Roads: 


132  (2)  0 

vice  1 
(3)  2 

3 


No  Data 
Ferry  Site 
On  Route  Ford  Site 
Electrified  Line 


0  No  Data 

1  All  Weather 

2  Fair/Dry  Weather 

3  Cart  Tracks 

4  Trails 


Type 


147 


149 


(  3  > 


APPENDIX  F 


VISTA:  VISION,  INTER V  IS  IB  I  LI TY ,  SURROGATE  TRAVEL,  TERRAIN 

ANALYSIS,  ANALYSIS 

(This  description  is  made  of  excerpts  from  the  abstract 
explaining  the  VISTA  systen,  written  by  D.  Hoffman,  D.  H. 
McCoy,  ana  H.J.de  St.  Germain,  US  Army  TRADOC  Systems 
Analysis,  Activity  White  Sands  Missile  Range,  New  Mexico 
88002-5562,  USA.) 

VISTA  is  a  new  interactive  terrain  analysis  graphics 
program  developed  by  the  Armored  Systems  Division,  US  Army 
TRADOC  Systems  Analysis  Activity  (TRASANA).  VISTA  can  be 
used  to  display  and  analyze  terrain  data  in  a  variety  of 
ways.  The  supporting  data  base  typically  consists  of 
elevations,  surface  features,  roads,  rivers,  hydrography, 
and  obstacles.  VISTA  currently  operates  on  a  12x12 
kilometer  area  at  100-meter  resolution.  The  terrain  data 
can  be  displayed  in  map  form  in  three  basic  ways:  as  shaded 
relief  (with  variable  sun  angle),  color  contours,  or  regular 
contours.  There  are  three  general  modes  with  which  the 
analyst  may  examine  various  aspects  of  the  data:  LINE-OF- 
SIGHT  (LOS),  PERSPECTIVE  VIEWING,  and  SURROGATE  TRAVEL.  LOS 
itself  may  also  be  displayed  in  three  different  ways. 

Profile  LOS  allows  the  user  to  select  the  standard  point-to- 
point  1 ine-of-s ight  which  may  be  used  to  help  determine 
locations  for  systems  placement  (e.g.,  weapons,  sensors,  or 
communications  equipment).  Masked  LOS  and  Multi-Sensor  LOS 
can  be  used  to  determine  1 ine-of-sight  for  various  forward 
observers,  surveillance  positions,  and  weapon  sites. 
PERSPECTIVE  VIEWING  allows  the  user  to  position  an  observer 
at  any  point  on,  or  outside  the  terrain,  and  to  obtain  a  3-D 
view  of  the  terrain  and  surrounding  features  as  they  would 
appear  from  that  point.  SURROGATE  TRAVEL  allows  the  user  to 
develop  animated  3-D  perspective  views  of  travel  along 
defined  surface  or  aerial  routes  within  the  terrain  area. 


1 .  Introduct ion 

VISTA  is  a  low-cost,  near  realtime,  sophisticated 
terrain  analysis  system.  The  acronym  VISTA  means  Vision, 
Intervisibility,  Surrogate  Travel,  Terrain  Analysis, 

Analysis  and  should  not  be  confused  with  the  Army  program 
VISTA,  which  means  Very  Intelligent  Surveillance  and  Target 
Acquisition.  The  package  was  developed  by  the  Armored 
Systems  Division  of  the  TRADOC  Systems  Analysis  Activity. 
Less  than  one  man  year  of  effort  has  been  expended  on  the 
initial  development  of  VISTA. 

2 .  Background 

Vista  was  developed  as  a  tool  to  perform  scenario 
development,  terrain  analyses  to  support  TRADOC  studies,  and 
as  an  ABCA  research  project.  The  number  of  requests  for. 
and  use  of  VISTA,  clearly  indicate  that  this  development  was 
indeed  a  step  in  the  right  direction.  To  our  knowledge, 
VISTA  is  the  most  effective  tool  of  its  kind  developed 
solely  by  Army  sources  without  contractor  help.  It  has  a 
variety  of  uses  and  operates  in  a  near  realtime  mode,  even 
for  complex  perspective  scene  generation. 

3 .  Vista  Capabilities 

VISTA  may  be  used  to  generate  two-dimensional  map 
displays  using  three  different  landform  representations. 
First,  one  may  display  an  ordinary  contour  map;  second, 
color  contour  banding  may  be  used  (eleven  color  bands  are 
available);  third,  shaded  relief  may  be  generated.  Surface 
features  may  be  added  to  all  three  forms.  These  features 
include  buildings,  vegetation,  roads,  rivers,  lakes,  and 
several  classes  of  obstacles. 

Three  forms  of  1 ine-of-sight  (LOS)  analysis  may  be 
conducted  with  VISTA.  These  include  profile  LOS,  masked 
LOS,  and  composite  LOS.  The  profile  LOS  allows  one  to  pick 
observer  and  target  locations;  VISTA  then  displays  a  terrain 
profile  between  those  points.  The  intervening  features  are 


exhibited  on  this  profile.  Masked  LOS  is  used  to  examine 
the  LOS  from  a  given  point  out  to  a  given  maximum  range. 
Those  areas  not  seen  are  masked  out  in  black.  Composite  LOS 
is  just  that,  a  combination  of  LOS  coverages  from  two  or 
more  sensors  using  up  to  eight  colors  to  show  the  union  and 
intersection  of  those  coverages.  Up  to  forty  sensors  may  be 
processed,  but  only  the  first  three  will  have  unique  colors 
to  indicate  the  various  coverages. 

Perspective  views  are  user — controlled,  in  that  the 
observer  locations,  direction,  and  viewing  angle  are 
selectable  in  the  two-dimensional  terrain  view.  The  three- 
dimensional  view  is  then  generated  and  displayed  above  the 
two-dimensional.  These  perspective  views  may  be  recorded  in 
series  to  provide  animated  travel  through  the  terrain. 

4 •  Vista  Hardware/Software  Requirements 

VISTA  runs  on  a  VAX  11/780  computer.  The  present 
implementation  contains  7500  lines  of  FORTRAN  code.  The 
graphics  device  used  is  a  RAMTEK  9400  with  eight  bit  planes. 
The  eight  bit  planes  are  configured  into  three  overlay 
planes.  Note:  The  shaded  relief  presentation  could  be 

improved  with  more  planes.  The  RAMTEK  driver  software 
(between  the  VAX  and  RAMTEK)  was  provided  by  RAMTEK.  The 
graphics  library  was  created  locally,  after  DI  3000  proved 
to  be  inadequate  for  most  TRASANA  applications. 

5 •  Vista  Algorithms  and  Data 

Two  LOS  algorithms  are  used  in  VISTA.  One,  the  so- 
called  DYNTACS  algorithm,  uses  quadratic  interpolation  to 
generate  elevation  values  between  grid  points.  The  other  is 
a  nearest  square  algorithm  called  the  Bresenham  algorithm 
because  it  was  adapted  from  Bresenham’s  straight  line  pixel 
lighting  algorithm. 

The  perspective  is  generated  by  defining  a  viewing 
window  in  the  world  coordinate  system.  The  scene  is 
projected  into  the  window  using  reflected  light  (a  function 


of  the  cosine  of  the  angle  between  the  light  source  and  the 
normal  to  the  terrain  surface).  The  scene  is  then  scaled  to 


fit  the  screen  coordinates.  The  scene  is  completely 
generated  on  the  VAX,  then  transferred  to  the  RAMTEK 
display. 

Defense  Mapping  Agency  (DMA)  terrain  data  are  used 
whenever  possible.  Because  of  content  and  resolution,  DMA 
CATTS/ ARTB ASS  data  are  preferred.  DTED  Level  I  is  used  for 
ground-to-ground  LOS  computations  as  a  last  resort,  due  to 
quality,  content,  and  the  WGS  coordinate  system. 

6.  Future  Plans  For  VISTA 

VISTA  is  being  modified  to  enhance  its  capabilities 
for  doing  terrain  analysis.  TRASANA  plans  to  use  the  system 
to  support  a  major  air  defense  study  (FAAD,  forward  area  air 
defense)  in  the  immediate  future.  Statistical  packages  from 
other  terrain  analysis  programs  will  be  modified  and  added 
as  time  permits.  As  hardware  improvements  become  available, 
it  is  believed  VISTA  can  be  modified  to  generate  full  screen 
perspective  views  in  less  than  a  second,  with  up  to  64 
levels  of  shading.  Scene  generation  using  display  lists  is 
being  investigated  on  a  Chromatics  system. 

7 .  VISTA  Availability 

VISTA  is  available  to  all  DoD  users.  Contractors 
are  asked  to  sign  a  memorandum  of  understanding  prior  to 
software  release.  To  date,  six  agencies  are  using  VISTA  for 
terrain  analysis  and  other  study  support. 

To  obtain  more  information  about  VISTA,  contact: 

Mr.  D.  Hue  McCoy 

US  Army  TRADOC  Systems  Analysis  Activity 

ATTN:  ATOR-TFC 

White  Sands  Missile  Range 

New  Mexico  88002-5502 

COMM:  (505)  678-1551/5891 

FTS :  898-1551/5891 

AVON:  258-1551/5891 


APPENDIX  G 

TDMS.C  PROGRAM  LISTING 


/****♦ 


TACTICAL  DIGITAL  MAPPING  SYSTEM 
PROTOTYPE 
by 

Maj.  S.  J.  Gaffney  and  Capt.  J.  E.  Daly 


This  program  was  written  on  an  IBM  PC  AT  and  equipped  with 
an  EGA  board  and  an  AT  clone  with  EGA.  Lattice’s  C’  Compiler 
ver.  3.1  was  used  in  conjunction  with  the  Essential  Software’s 
"C  Utility  Library” , ver .  3.0.  Mouse  Systems'  PC  Paint  ver.  1.5 
was  also  used  to  create  the  binary  .PIC  files  called  into  the 
program . 

This  program  is  used  in  conjunction  with  another  program  named 
CREATE. C  to  produce  the  functioning  prototype  program. 


***♦*/ 

m 

I*****  Syste»  Variables  ***** / 
linclude  “colors. h" 
linclude  “ctype.h" 
linclude  “dos.h" 
linclude  "error. h“ 
linclude  "filedata.h’ 
linclude  "graphics. h“ 
linclude  "intreqs.h' 
linclude  "aath.h" 
linclude  'stdio.h' 


/*****  Global  Variables  *****1 
Idefine  8ACKGRND  BLUE 
•define  FOREGRND  YELLOW 
Idefine  ERRCOLOR  YELLOW 
Idefine  FORTY  0 
Idefine  EIGHTY  2 
Idefine  HIGH  2 
Idefine  MEDIUM  1 
Idefine  TEXT  0 


I*  Background  color  * / 

'/*  Foreground  color  »/ 

!*  Foreground  color  */ 

/*  Code  for  forty  column  lode  */ 
I*  Code  for  eighty  coluin  «ode  */ 
I*  High  res  code  */ 

/♦  Medium  res  code  »/ 

I*  Text  »ode  code  *1 


long  int  stack  =  40000; 

gvideoU: 


*  * 

*  MAIN  * 

*  * 


mitgrafiO,  0,  0): 
iogos! I: 

clscoJor  (F0RE6RND,  BACK GRND) ; 
border  (BACKGRND): 
sysaaini): 

done  :  imtgrafiO,  0,  0); 
return; 

\ 


I*  Clear  screen  and  set  to  hires  node.  */ 

/*  Starting  logos.  */ 

/*  Clear  screen  and  set  colors.  */ 

/*  Set  border  color.  */ 

/*  Call  the  sys.aain  routine.  */ 

/*  Set  screen  display  to  hi-res  and  set  colors.  */ 


»  * 

*  SY3MAIH  * 

*  * 

sys»ain  () 


int  key; 
ciearkbdO: 

clscolor  (FOREGRND,  BACKGRND) ; 
page  ( "MAIM.MNU” ) : 
cur locat  (23,  30); 

■enuloop.-  tiaeloopO; 
ecokey  (ikey); 
smtcn  (key) 


I*  Local  integer  variable.  */ 

I*  Clear  keyboard  buffer.  */ 

I*  Clear  screen  and  set  colors.  »/ 

I*  Display  the  Main  Nenu  screen.  */ 

I*  Hove  cursor  to  location  (23,30).  */ 

I*  Display  an  active  date  and  tiie.  */ 

I*  Wait  for  key  pressed  and  print  it  on  screen.  *1 
I*  Set  up  for  aenu  selections.  »/ 


case  T;  intelsysO; 

clscolor  (FOREGRND,  BACKGRND): 
page  ( "MAIN.HHU" ) ; 
cur locat  (23,  30); 
goto  aenuloop; 

case  ’2’;  ops  sys(); 

clscolor  (FOREGRND,  BACKGRND); 
page  CHAIN. HNU“): 
cur locat  (23,  30); 
goto  aenuloop; 

case  ’3’;  logs  sys(); 

clscolor  (FOREGRND,  BACKGRND); 
page  CHAIN. HNU'); 
cur locat  (23,  30); 
goto  aenuloop; 

case  '4':  fire  sys(); 

clscolor  (FOREGRNO,  BACKGRND); 
page  CHAIN. HNU'); 
curlocat  (23,  30): 
goto  aenuloop; 


I*  Call  the  Intelligence  Routine.  */ 
I*  GO  BACK  TO  HAIN  NENU  */ 


I*  Call  the  Operations  Routine.  »/ 
I*  GO  BACK  TO  HAIN  HENU  */ 


/*  Call  the  Logistics  Routine.  *1 
I*  GO  BACK  TO  HAIN  HENU  »/ 


/♦  Call  the  Fire  Support  Routine.  */ 
/*  GO  8ACK  TO  HAIN  HENU  */ 


case  ’5’:  quitd; 

clscolor ( FOREGRNO,  BACKGRND); 
page  ( ‘MAIN. HNU" ) ; 
curlocat  (23,  30): 
goto  tenuloop; 
default:  error!); 

goto  »enuloop; 


I*  EXIT  TO  DOS0  *1 

/*  HO")  GO  BACK  TO  MAIN  MENU  */ 


/ *************************** ************************************* ************** 
*  * 

*  INTELLIGENCE  SUBSYSTEM  ROUTINES  * 

*  * 

******************************************************************************/ 

intelsys( ) 


{ 

int  key; 
clearkbdO: 

clscolor  (FOREGRNO,  BACKGRND): 
page  ("INTEL. HNU"); 
curlocat  (23,  30); 
lenuloop.-  tiieloopO; 
ecokey  (&key); 
shi ten  (key) 


1 


case  T:  doscidl “create.exe"  I; 
clscolor (FOREGRNO,  BACKGRND); 
page  (“INTEL. HNU"!; 
curlocat  (23,  30); 
goto  lenuloop; 

case  '2':  doscidCcreate.exe"); 
clscolor (FOREGRNO,  BACKGRND); 
page  ("INTEL. HNU"); 
curlocat  (23,  30): 
goto  lenuloop; 

case  '3':  notyetO; 

cl SCO lor (FOREGRNO,  BACKGRND): 
page  ("INTEL. HNU"); 
curlocat  (23,  30); 
goto  lenuloop; 

case  ’4’;  notyetO; 

clscolor (FOREGRND ,  8ACKGRND); 
page  ("INTEL. HNU"); 
curlocat  (23,  30); 
goto  lenuloop; 


/*  Local  integer  variable.  */ 

I*  Clear  keyboard  buffer.  */ 

/*  Clear  screen  and  set  colors.  */ 

I*  Display  the  Intelligence  Menu  screen.  »/ 

/*  Hove  cursor  to  location  (23,31).  */ 

/*  Display  an  active  date  and  tue.  */ 

I*  Wait  for  key  pressed  and  print  it  on  screen. 
/*  Set  up  for  ienu  selections.  */ 


I*  DISPLAY  A  NAP  »/ 

/*  GO  BACK  TO  INTEL  HENU  */ 


I*  DISPLAY  A  HAP  *1 
I*  GO  BACK  TO  INTEL  HENU  ♦/ 


I*  Cali  the  NotYet  Routine.  */ 
/*  GO  BACK  TO  INTEL  HENU  */ 


/♦  Call  the  NotYet  Routine.  */ 
I*  GO  BACK  TO  INTEL  HENU  */ 


case  ’5’;  quitO;  /»  EXIT  TO  DOS  7  */ 

clscolor (FOREGRND,  BACKGRND):  /»  NO--)  GO  BACK  TO  INTEL  HENU  */ 
page  ("INTEL. HNU"); 
curlocat  (23,  30); 
goto  lenuloop; 
default:  error!) ; 

goto  tenuloop; 


*  » 

*  OPERATIONS  SUBSYSTEM  ROUTINES  * 

*  * 

OPS  SYS < ) 


int  key: 
clearkbdO: 

c 1  sc 0 1 of  (EOREGRND,  BACKGRND ) : 
page  (“OPS.HNU" ) : 
curlocat  (23,  30): 

•emj loop :  tiieioopO: 
ecokey  (Skey ) ; 
switch  (key) 


i*  Local  integer  variable.  */ 

/*  Clear  keyboard  buffer.  */ 

I*  Clear  screen  and  set  colors.  */ 

I*  Oispl’ay  the  Operations  Menu  screen.  */ 

I*  Move  cursor  to  location  (23,31).  *j 
/*  Display  an  active  date  and  tue.  */ 
ft  wait  for  key  pressed  and  print  it  on  screen 
I*  Set  up  for  *enu  selections.  */ 


case  'l':dosc»d( "create. exe'); 
clscolorlFOREGRND,  BACKGRND): 
page  (“OPS.MNU"); 
curlocat  (23,  30); 
goto  aenuloop: 

case  ’2’:  doscedfcreate.exe"): 
clscolorlFOREGRND,  BACKGRND): 
page  (“OPS.MNU"): 
curlocat  (23,  30); 
goto  aenuloop: 

case  ’3’:  doscadCcreate.exe"); 
clscolorlFOREGRND,  BACKGRND); 
page  ( “OPS.MNU"): 
curlocat  (23,  30): 
goto  aenuloop; 

case  '4':  doscadCcreate.exe"); 
clscolorlFOREGRND,  BACKGRND): 
page  ("OPS.MNU"): 
curlocat  (23,  30): 
goto  aenuloop; 

case  '5':  guitO; 

clscolorlFOREGRND,  BACKGRND): 
page  (“OPS.MNU'): 
curlocat  (23,  30): 
goto  aenuloop; 

default:  error!); 

goto  aenuloop; 


It  DISPLAY  A  HAP  »/ 

It  GO  BACK  TO  OPS  MENU  »/ 


/t  DISPLAY  A  MAP  ♦/ 

/*  GO  BACK  TO  OPS  MENU  ♦/ 


/*  DISPLAY  A  MAP  ♦/ 

/*  GO  BACK  TO  OPS  MENU  »/ 


/*  DISPLAY  A  MAP  */ 

/*  GO  BACK  TO  OPS  MENU  */ 


/t  EXIT  TO  DOS  ?  */ 

I*  NO-YGO  BACK  TO  OPS  MENU  */ 


/nmttttntttttmmtttmttttttmttttttmtmttttttmttmttttmttttttt 
*  * 

t  LOGISTICS  SUBSYSTEM  ROUTINES  * 

*  » 

logs.sysO 


int  key; 
clearkbdO: 

clscolor  (FOREGRND,  BACKGRND); 
page  CLOGS. MNU“); 


/♦  Local  integer  variable.  »/ 

/*  Clear  keyboard  buffer.  »/ 

I*  Clear  screen  and  set  colors.  »/ 

/*  Display  the  Logistics  Menu  screen.  */ 


c ur local  123,  30);  /*  Move  cursor  to  location  (23,31).  */ 

•enuloop;  t ue loop U:  /*  Display  an  active  date  and  tue.  */ 

ecovey  (ikey);  jt  wait  for  key  pressed  and  print  it  on  screen.  */ 

snitch  ikeyi  /»  set  up  for  tenu  selections.  »/ 

\ 

case  ’1':  dosc«d( “create . eve" ) :  /*  DISPLAY  A  MAP  */ 

clscoloMFOREGRND,  BACKGRND) ;  /*  GO  BACK  10  LOGS  MENU  */ 

page  ( "Li'GS . MNU" ) : 
curiocat  (23,  30 i: 
goto  aenuioop; 

case  ’2’:  doscidl "create. eve" ) :  /*  DISPLAY  A  MAP  »/ 

c lscoior (FOREGRHD .  BACKGRND);  /*  GO  BACK  10  LOGS  MENU  »/ 
page  CLOGS.HNU*); 
curiocat  (23,  30); 
goto  *enuloop; 

case  ’3’:  doscad(*create.e*e');  /*  DISPLAY  A  MAP  */ 

C lscoior (FORESRND,  BACKGRND);  /«  GO  BACK  10  LOGS  MENU  »/ 
page  CLOGS. MNU*); 
curiocat  (23,  30); 
goto  lenuloop; 

case  ’4’:  dosc«d( “create. ene*);  /*  DISPLAY  A  MAP  */ 

C lscoior (FOREGRND,  BACKGRND);  /*  GO  BACK  10  LOGS  MENU  */ 
page  CLOGS. MNU*); 
curiocat  (23,  30); 
goto  lenuloop; 

case  ’5’:  quitO:  /*  EXIT  TO  DOS?  */ 

clscolor IFOREGRND,  BACKGRND):  /♦  NO— >G0  BACK  10  LOGS  MENU  »/ 
page  CLOGS. MNU*); 
curiocat  (23,  30); 
goto  lenuloop; 

default;  error?); 

goto  tenu  loop-, 


*  » 

*  FIRE  SUPPORT  SUBSYSTEM  ROUTINES  * 

*  » 

fire.sysO 


1 

int  key. 
dearkbdO; 

clscolor  (FOREGRND,  BACKGRND); 
page  (“FIRE  SUP.HHU") ; 
curiocat  (23,  30); 

•enuioop;  tiaeloopO: 
ecokey  (ikey); 
snitch  (key) 


/*  Local  integer  variable.  ♦/ 

I*  Clear  keyboard  buffer.  */ 

I*  Clear  screen  and  set  colors.  »/ 

/*  Display  the  Fire  Support  Menu  screen.  */ 

I*  Move  cursor  to  location  (23,31).  »/ 

/*  Display  an  active  date  and  tiae.  */ 

I*  Wait  for  key  pressed  and  print  it  on  screen.  */ 
/»  Set  up  for  tenu  selections.  */ 


case  T:  notyetO: 

clscolor (FOREGRND,  BACKGRND); 
page  (“FIRE  SUP. MNU  ); 
curiocat  123,  30); 
goto  tenu loop; 


/♦  Call  the  NotYet  Routine.  */ 
/*  SO  BACK  TO  FIRE. SUP  MENU  */ 


rase  dosc«d( 'create.exe' >; 

c 1 sco lor ( f OREGRNO ,  6ACKGRND > : 
page  ('FIRE  SUP.HNU  ); 
curlecat  123,  30); 
goto  aenuloop; 

:asr  gosc«d(“create.e*e“); 

c Iscolar ( FOREGRHO.  BACKGRND); 
Page  ( ‘FIRE  SUP.HNli  ); 
cur  local  (23,  30); 
goto  aenuloop; 

case  ’i’:  jcsf»d("cie<ite.e*e"); 

C  Isco lor (FOREGRND ,  BACXGRND ) : 
page  ("FIRE  SUP.HNU  ); 
cur  local  123,  30); 
goto  aenuloop; 

case  '5':  quit!); 

clscoior (FOREGRND ,  8ACKGRHD) : 
page  i "FIRE  SUP.HNU  ) ; 
curlocat  (23,  30); 
goto  aenuloop: 

default:  error!); 

goto  aenuloop; 


/«  DISPLAY  A  MAP  */ 

I*  GO  BACK  f(i  FIRE. SUP  MENU  */ 


/*  DISPLAY  A  HAP  *1 

I*  GO  BACK  10  FI  RE. SUP  MENU  */ 


I*  DISPLAY  A  HAP  »/ 

!*  GO  BACK  10  FIRE. SUP  MENU  */ 


/*  EXIT  TO  DOS  ?  */ 

/*  NO-)GO  10  FIRE. SUP  MENU  */ 


*  * 

*  SUBSYSTEM  UTILITY  ROUTINES  * 

*  * 

/tmmmmtm*mtm*m*m*mt****m*m*m***mmm*m**m*m 
♦  » 

'  FLASH  * 

*  * 


The  flash  routine  writes  a  stored  graphics  file  to  the  screen  buffer  and  displays  it  on  the  aonitor. 
PARAMETERS: 

screen  -  file  naie  with  the  graphics 
resolution  -  screen  resolution 
palette  -  palette  used  (0  or  1) 
bakgrnd  -  background/border  color 
*m*/ 


flash ( screen,  resolution,  palette,  bakgrnd) 

char  *screen[];  y 

int  resolution,  palette,  bakgrnd;  / 


/*  Set  a  pointer  to  external  character  screen  array.  */ 
I*  External  integer  variables.  »/ 


char  buff [16400]; 

struct  intreus  regs; 

unsigned  failure,  handle,  actual; 


I*  Initialize  a  character  buffer.  */ 
/»  Local  structure  variables.  */ 

/*  Local  unsigned  variables.  */ 


/****»  Read  in  the  liage.  **»*»/ 

if  v \ f ai iure-openf 1 1 (screen .O.ihandie) >  >  0) 
t 

ciscolor  (FOREGRND,  8ACKGRND):  /*  Clear  screen  and  set  colors.  »/ 

curlocat  (  ‘5,  0);  /*  Start  writing  at  cursor  location  (9,0).  »/ 

colrprts  {"ttmmtt  FLASH  cannot  open  screen  file  **********  “  ,ERRCOLOR,BACI(GRND): 
curlocat  (11.  10):  /*  Start  writing  at  cursor  location  (11,10).  */ 

colrprts  (screen,  FOREGRND,  BACkGRND);  /*  Print  screen  in  set  colors.  */ 
curlocat  (13,  10):  /*  Start  writing  at  cursor  location  (13,10).  */ 

colrprts  ('  Press  a  key  to  continue",  FOREGRHD,  BACK6RND); 
return; 
t 

reaofil  (handle,  1p400,  buff,  factual ) ;  /*  Read  the  binary  data  into  te»porary  file.  */ 

closefil  (handle);  /*  Close  the  teiporary  file.  */ 

mitgraf  (resolution,  palette,  bakgrnd):  /*  Initialize  the  graphic  screen.  */ 

udosint  (0,  Aregs,  Areas):  /*  Get  the  segient  value.  */ 

segiov  ilpj7b,  stuff [7],  reqs.ds,  0,  OxbBOO):  /*  Flash  the  iiage  into  the  screen  buffer.  */ 

return: 


immmtmmummtmmmttmmmmttmmmmmmmmm 
»  * 

*  PAGE  * 

♦  * 
Mmmmmmrmmmmmmmtmmtmmmmtmmrnmm**/ 

/****♦ 

Page  writes  a  screen  of  tent  (ASCII)  to  the  screen. 

PARAMETERS: 

page  f i le  —  na»e  of  text  file 
CONTROL  CODES: 

.c  n  -  Center  the  next  n  lines. 

.e  -  Echo  the  output  to  the  printer  if  the  user  requests  it. 

.■  -  Display  the  centered  wessage:  'Press  any  key  to  continue  or  Q  to  quit' 
on  line  24.  Pressing  a  key  causes  screen  erasure. 

Pause.  Pressing  a  key  causes  screen  erasure. 

Forty  ccluin  lode  (erases  screen). 

Eighty  colu«n  lode  (erases  screen). 


■  P 
.4 
.0 

****+/ 


I*  Set  pointer.  * / 


page  (paqe  file) 
char  *page.  f i le; 

( 

int  cent,  col,  i,  *ode,  pflag,  plines,  row;  /*  Local  integer  variables.  */ 

char  *f lag;  /*  Set  pointer.  */ 

char  line[80];  /*  Open  character  array  of  80.  *1 

FILE  tinfile,  *fopen();  /*  Set  pointers.  *1 

pflag  =  0;  /*  Initialize  pflag  value.  */ 

/mm  open  the  page  file  ****»/ 

if  (< inf ile  :  fopen  (page.file,  V))  ==  NULL) 


clscolor  (FOREGRND,  BACK6RN0) ;  /*  Clear  screen  and  set  colors.  */ 

curlocatl  0,  0);  /*  Start  writing  with  cursor  at  (9,0).  */ 

mmm*  page  cannot  open  text  file.  **********  *  ,  FOREGRND,  BACKGRND); 
il,  10);  /»  Start  writing  with  cursor  at  (11,10).  »/ 

page  file,  FOREGRND,  BACKGRND):  /*  Clear  screen  and  set  colors.  */ 

24,  30);  I*  start  writing  with  cursor  at  (23,33).  */ 


colrprts 

curlocat 

colrprts 

curlocat 

return; 


/*>»»*  Seqin  reading  in  te«t.  **»*»/ 


row  :  0;  /*  Initialize  row  value.  *1 

cent  :  0:  i*  Initialize  rent  vaiue.  */ 

while  ttrlaq  -  t'oets  (line,  80,  infile)!  M  NULL1 

1 

it  lline[Oj  /*  If  1st  line  array  value  :  .  then  ...  */ 

t 

"in  Interpret  the  couand.  **»**/ 

switch  tiine[l].i  /*  Set  up  couand  code  variable  array.  */ 

i 


*****  .c  n  -  Center  the  ne»t  n  lines.  ♦****/ 

case  V: 

cent  :  atoi  tlline[2]i: 

break;  /*  Break  out  of  the  loop.  */ 


/****»  .e  -  Echo  the  output  to  the  printer.  ♦****/ 


case  e  : 

clscolor  (FOREGRND,  6ACKGRN0) :  /*  Clear  screen  and  set  colors.  */ 
curlocat  112,  23);  /«  Start  writing  with  cursor  at  (12,  23).  */ 

colrprts  C  Do  you  want  printed  output  ( r/H)?* ,  FOREGRND, BACKGRND); 
if  ( getyesnol 1 ) )  I*  Get  Boolean  value  of  Y/N  input.  */ 

pt lag  -  1;  /*  Set  pfla9  value.  */ 

^  for  ( i ;  1 ;  i  <:  b:  i**)  IprtlfO;  I*  Print  line  for  i  1  to  6  tues.  */ 

clscolor  (FOREGRND,  BACKGRND);  /*  Clear  screen  and  set  colors.  */ 
piines  :  0;  It  Initialize  value.  *1 

break;  /*  Break  out  of  the  loop.  *1 


/ttttt  .i  -  Display  the  centered  lessage;  'Press  any  key  to  continue  or  Q  to  quit' 
on  line  24.  Pressing  a  key  causes  screen  erasure.  *****1 

case 

getsciod  t&iode,  ii,  ii):  I*  Get  screen  display  »ode  integer  value.  */ 

if  dode  <:  1)  curlocat  (24,  2);  /*  If  Boolean  false,  start  writing  at  curcor  location  (24,  2).  »/ 
else  curlocat  (24,  21):  /*  Start  writing  with  cursor  at  (24,  21).  */ 

colrprts  C  Press  any  key  to  continue  or  Q  to  quit',  FOREGRND,  BACKGRND); 

I*  Wait  for  key  pressed.  */ 
ft  If  key  pressed.  *1 


getkey(Ji); 

if  Ml  ::  V> 


{ 


1 


(l  " 


’)) 


fciose  (infile); 
if  (pflag) 
IprtfM); 
return; 


I*  If  pflag  set.  t/ 
I*  Print  infile.  */ 


clscolor  (FOREGRND,  BACKGRND):  I*  Clear  screen  and  set  colors.  *1 
row  :  0:  /*  Initialize  row  value.  */ 

break:  /t  Break  out  of  the  loop.  */ 


/ttttt  .p  -  Pause,  ttttt/ 


case  V- 


pauseO; 
row  =  0; 
break: 


I*  Wait  for  key  pressed.  */ 
/*  Initialize  row  value.  »/ 
I*  Break  out  of  the  loop.  */ 


91 


/****»  .4  - 


Forty  coluin  lode  (erases  screen).  **»*♦/ 


D 


vs» 

vjv 

;vy 

y,y 

,VV 
,v;y 
*'  ** 

LT 


case 

setsciod  (FoRTO-  /»  jet.  screen  display  lode  to  40  columns.  */ 

border  < 6ACKGRN0 1 :  ./*  Set  border  color.  »/ 

clscolor  (FOREGRND,  EACKGRND ) /*  Clear  screen  and  set.  colors.  *! 

row  :  0:  /*  Initialize  row  value.  »/ 

break;  /*  Break  out  of  the  loop.  *1 


/****♦  .8  -  Eighty  coluin  lode  (erases  screen).  »**»*/ 


case  ’8’: 


setsciod  (EIGHTY);  /*  Set  screen  display  lode  to  80  coiuins.  »/ 

border  (8ACKGRND) ;  /»  Set  border  color.  */ 

clscolor  (FoREGRND,  8ACKGRND) :  /*  clear  screen  and  set  colors.  */ 

row  :  0:  I*  Initialize  row  value.  */ 

break;  /*  Break  out  of  the  loop.  »/ 


line  (strlen  (line)  -lj  -  ’\0’;  /*  Print  the  line.  */ 
if  (cent  >  Oi 

{ 

/ *****  Process  centered  lines.  ***♦*/ 

getsciod  Uiode,  4i,  4i);  I*  Determine  display  lode.  */ 

--cent-  I*  Decreient  cent.  »/ 

if  («ode  <:  1)  col  ;  (40  -  strlen  (line))  12;  /*  Calculate  center  of  line  if  40  col.  lode.  »/ 
else  col  ;  (80  -  strlen  (line))  12;  I*  Calculate  center  of  line  if  83  col.  lode.  */ 

else  col  ;  1:  /»  Set  col  ^  1.  */ 


else  col  ;  1: 
if  (row  >:  24) 

1 

row  :  0; 

if  (pflag  44  (plines  >  54)) 

( 

plines  =  0; 

IprtffO: 


I*  Initialize  row.  */ 

/*  If  pflag  set  and  nuiber  of  lines  >  54.  */ 

/*  Initialize  plines.  */ 

,/»  Print  line.  */ 


for  (i:i;  i  <■-  6;  i++)  IprtlfO;  /*  Increient  i  froi  1  to  6.  */ 


if  (pflag) 


/*  If  pflag  set.  */ 


if  (col  )  1)  for  (r-1:  l  <  col;  i++)  lprtchar (0,  ’  ’); 
lprtstr  (line);  /*  Print  string.  */ 

lprtcrl ); 

iprtlft);  /»  Print  line.  */ 

plines^;  /»  Increient  plines.  ♦/ 

curlocat  (++row,  col);  I*  Start  writing  with  cursor  at  (row, col).  */ 

colrprts  (line,  FOREGRND,  BACXGRND);  /»  Clear  screen  and  set  colors.  */ 


Clear  screen  and  set  colors.  *1 


fclose  (infile): 
if  (pflag) 
IprtffO; 
return; 


I*  Close  file  buffer.  »/ 
/»  If  pflag  set.  */ 

/*  Print  infile.  */ 


tlMmMIIMMMMtUMMMIIIMUMtltMHMitMMMMtMMItOMimmm 
*  * 

•  TIHELOUP  » 

'  t 

mmiimmimmmmimKtMmtttmMmmmmimmmmmiii 

/**»►« 

! i*ei oop  displays  the  syste*  ti»e  and  date  at  the  bottoe  of  the  »enu  title  board. 

PARANE IERS: 

None. 

him; 

t.teicopi i 


in t  i,  i ,  ton,  col: 

:#K  fit;?!; 

clearkbdi): 
curgetl&row,  4coD; 
fort  ;  ;  ) 


•. ur type  (1,  G,  01; 

if  Hi  ;  checkkey(l)  1)  break; 

systiae  (4t«,  9); 

svsdate  Udt,  24): 

curlocat  (  8,18); 

colrprt$(dt .FOREGRND.BACKGRND) : 

curlocatt  8,521; 

colrprts  (ti,  F0REGRN0,  B ACKGRND ) ; 

curlotat(roN.col); 

curtype(0,6,7) ; 

for  (i  :  1;  i  (:  1000;  1++) 


/*  Local  integer  variables.  */ 

/*  Date  display  buffer.  »/ 

/*  Ti»e  display  buffer.  </ 

/*  Clear  keyboard  buffer.  */ 

I*  Place  cursor  at  location  of  pointers  iron, col t 
/*  Start  infinite  loop.  ♦/ 


/*  Turn  cursor  off.  */ 

I*  Wait  for  key  pressed.  »/ 

/*  Load  the  systue  buffer  in  the  19  foriat.  */ 

/*  Load  the  sysdate  buffer  in  the  124  foriat.  */ 

I*  Start  writing  at  cursor  location  (8,12).  * / 

/*  Print  contents  of  the  sysdate  buffer  in  set  colors.  »/ 
/*  Start  writing  at  cursor  location  (8,46).  */ 

/»  Print  contents  of  the  systue  buffer  in  set  colors.  */ 
/»  Start  writing  at  cursor  location  (row.col).  »/ 

I*  Turn  cursor  on  and  set  colors.  V 

!*  Increment  i  fro«  1  to  1000.  */ 


if U.i  :  checkkey ( ) )  "  1)  goto  done;  /♦  On  key  pressed  log  off  and  exit  to  DOS.  */ 


done;  curtype(0, (>,/); 
return; 


/*  Turn  cursor  on  and  set  colors.  *1 


•  * 

*  TIHEUINOON  » 

*  » 

/»»»*♦ 

Tieewindow  displays  the  syste*  tue  and  date  in  the  bottoi  right  corner  of  the  screen  when  control 
t  is  pressed.  Control  t  again  turns  it  off. 

PARAMETERS: 

None. 

!»»»*/ 

tiaewindowl) 


int  1,  J; 
char  tipefU), 
t«[8J; 


I*  Local  integer  variables.  »/ 
/*  Tue  display  buffer.  »/ 


'’’VZ.'T.'? 


Ip* 


.'.‘/■I 
'V> 


systue  i&tue,  f): 

svstue  < &ti.  ,J) : 

sapaindo  '?i,  '2.  24,  7<<,  t lie ) : 

furiocat!24,<21: 

colrprts  iti,  FOREGRND,  BACKGRND) : 
for  i.i  ;  l:  i  c  1000;  iHt 


!*  Start  infinite  loop.  */ 

/*  Load  the  svstue  buffer  in  the  If  foriat.  »/ 

/*  Load  the  svstue  buffer  in  the  If  foriat.  »/ 

/*  Open  aindoa  in  bottoi  right  corner  of  screen.  »/ 

/»  Start  anting  at  cursor  location  (24, 72‘ .  */ 

/*  Print  contents  of  the  systue  buffet  in  set  colors.  »/ 
/*  Increment  i  fro*  l  to  1000.  V 


lfltj  -  cherney*  1 1  -  N  goto  done:  /»  On  key  pressed  log  off  and  eut  to  DOS.  »/ 


done;  curtype(0,t>,7); 
sapaindC'24.  ’2,  2*,  7'3.  fuel; 


/*  Turn  cursor  on  and  set  colors.  ♦/ 

/*  Close  aindoa  in  bottoi  right  corner  of  screen.  */ 


*  * 

«  HEAD  * 

»  4 

. . . 

/m«t 

The  head  routine  clears  the  screen  and  prints  the  character 
string  in  title  centered  on  line  1.  Eighty  coluin  lode  is  used. 

PARAMETERS: 

None. 

44444/ 

headtUtlel 

char  *title:  /♦  Pointer  to  external  character  variable.  »/ 


clscolorfFofiEGRND, BACKGRND); 
l  -  (80  -  strlen  (title))  / 2; 
cur locat ( 1 , i ) : 

colrprtsi title, FOREGRND, BACKGRND): 
return; 


I*  Local  variable.  */ 

/*  Clear  screen  and  set  colors.  *1 
/*  Calculate  center  of  the  line.  */ 

/*  Start  anting  at  cursor  location  (1,1) 
/*  Print  title  in  set  colors.  */ 


' 444  44  444444444  4X4444444444444X44444444444444444444444444444444444444444444444 
4  4 

»  LOGOS  * 

4  4 

4X444444444444444444444444444444444444444444444444444444444444444444444444444/ 

/  44444 

The  logos  routine  displays  the  logos  at  the  beginning  of  the  dialog. 
PARAMETERS: 


ioqos1'  > 

{ 

initgraff 0.0,0) : 
clearkodO: 

f  Iashf  TITLE.  PIC" , MEDIUM, G, BLACK ) : 
syspsany iO , 0,5,0): 
irutgraf(0,0,0); 

1 


!*  Set  display  to  hires  »ode,  black  on  black.  */ 
/*  Clear  keyboard  buffer.  */ 

/*  Call  flash  to  display  TITLE.  */ 

/*  Wait  for  five  seconds  or  key  pressed.  */ 

/*  Set  display  to  hires  lode,  black  on  black.  */ 


/ ************************************************ ***************************** 
*  t 


* 


PAUSE 


* 


* 


* 


*******************************$****11***************************************/ 


****** 

cause  causes  a  pause  until  a  key  is  pressed. 

PARAMETERS: 

None. 

***♦*/ 


pause  I ) 

{ 

mt  i: 

dearkbdl  I : 
for  (  ;  ;  j 

{ 

if U l  ;  checkkeyU)  ::  1)  break; 

1 

dearkbdl. i: 

cisco  lor  ( F  iREGRND ,  5ACKGPN?1: 


I*  Local  Boolean  variable.  */ 

/*  Clear  keyboard  buffer.  */ 

/*  Starts  an  infinite  loop.  */ 

/*  Poll  keyboard  for  an  input.  */ 

it  Clear  keyboard  buffer.  */ 

screen  and  set  colors.  »/ 


/************♦♦****************♦********************************************** 
»  * 

*  NOT YET  * 

*  * 
ttm** ******* ****** ******* *****************  mm***************************/ 


/♦**** 

Notyet  is  a  du»iy  routine  to  hold  a  place  for  future  functions. 


PARAMETERS: 

None. 

MENU: 


THIS  FUNCTION  NOT  YET  IMPLEMENTED 


MICROCOPY  RESOLUTION  TEST  CHART 
NATIONAL  BUREAU  OF  STANDARDS- 1963-A 


notyetO 


int  i: 

c Iscolor (FOREGRND.BACKGRND) : 

page  i “NOTYET .MNU” ) : 

cur  type  (0,  0,  0): 

curlocat  (24,  1): 

getkey(Si); 

cur  type  (0,  0,  0): 

sysiainO: 


I*  Local  integer  variable.  */ 

/♦  Clear  screen  and  set  colors.  »/ 

I*  Display  the  notyet  lessage.  ♦/ 

I*  Turn  off  cursor.  »/ 

I*  Set  cursor  at  location  (24,1).  »/ 
I*  Wait  for  key  pressed.  */ 

/*  Turn  on  cursor.  */ 

I*  Return  to  sysiain  routine.  */ 


/***«************************************************************************* 
»  4 

*  ERROR  * 

*  * 
tt****tm****m************************************************************/ 


/ ***** 

The  error  routine  beeps  the  speaker  and  returns  the  cursor  to  the  sale  colum,  previous  row. 
It  is  used  to  signal  bad  data  input. 

PARAMETERS: 

None. 

****♦/ 


error ( ) 


int  row,  col: 
curaet  (iron,  icol); 
curlocat  (row,  col  -  1): 
beepO; 
return: 


I*  Initialize  rou.  col  integer  variables.  */ 

I*  Set  location  of  cursor  at  pointers  row,  col.  */ 
/*  Start  writing  at  cutsor  location  (9,2).  »/ 

I*  Sound  the  error  warning.  »/ 


/♦****« *********************************************************************** 
*  * 

*  ERRMSS  * 

*  * 
mm***********************************************************************/ 


/***♦* 

This  routine  prints  a  centered  error  lessage  on  lineno,  beeps  once  and  pauses. 
The  user  strikes  a  key,  the  lessage  is  cleared  and  control  is  returned. 


PARAMETERS: 

lineno  --  Location  of  the  cursor  and  the  error  lessage. 
isg  -  Error  lessage  to  be  printed. 

**♦**/ 


errisg  (lineno,  isg) 

int  lineno:  /»  External  integer  variable.  */ 

char  »isg:  /♦  Pointer  to  external  character  variable.  */ 


int  i,  lode: 

getsciod  (iiode,  &i,  &i); 
if  (lode)  i  =  (30  -  strlen  (isg))  /2; 
else  i  :  (40  -  strlen  (isg))  / 2; 
curlocatllineno,  i); 
colrprtsiisg,  ERRC0L0R,BACKGRND); 
beepO: 
getkey  tti): 
curlocatllineno,  i): 


I*  Local  integer  variables.  */ 

/»  Detenine  screen  display  lode  and  set  colors.  */ 

/<  Calculate  center  of  string  in  80  colum  lode.  */ 

I*  Calculate  center  of  string  in  40  colum  lode.  »/ 

I*  Start  writing  at  cutsor  location  (9,2).  »/ 

I*  Print  in  set  colors.  */ 

I*  Sound  error  warning.  »/ 

I*  Wait  for  key  pressed.  »/ 

I*  Start  writing  at  cutsor  location  (9,2).  »/ 


colrprts(  * 


FOREGRND.BACXGRND):  /*  Print  in  set  colors.  */ 


1 


QUIT 


/****♦ 

Quit  causes  the  prograa  to  exit  to  DOS. 


PARAHEFERS: 

None. 


MENU: 


fOU  ARE  ABOUT  TO  EXIT  TO  DOS  ! ! ! 


Quit  I) N? 


c|uit() 
int  i; 

clscolor  (FOREGRND,  8ACKGRND); 

clearkbdO: 

page  (‘QUlf.HWT); 

curlocat  (24,  30); 

tiaemndouO: 

i:  ecoyesno(24,  30,  1); 
if  (1  "  U 

mitaraf  (0,  0,  0); 

^  exitD : 

else 

sysaainO; 


I*  Local  integer  variables.  »/ 

I*  Clear  screen  and  set  colors.  »/ 

/*  Clear  keyboard  buffer.  »/ 

/»  Display  the  Exit  Menu.  */ 

/*  Set  cursor  at  location  (24,30).  */ 

/»  Puts  tiae  in  loner  right  corner  of  screen  in  reverse  video.  */ 

I*  Check  keyboard  for  a  Y/H  input  with  echo.  */ 


/*  Clear  screen.  */ 
/*  Exit  to  DOS.  ♦/ 


/»  Return  to  sysaain  routine.  */ 


APPENDIX  H 

CREATE. C  PROGRAM  LISTING 


/***«* 


TACTICAL  DIGITAL  MAPPING  SYSTEM 
PROTOTYPE 
by 

Maj.  S.  J.  Gaffney  and  Capt.  J.  E.  Daly 

This  prograa  is  required  for  operation  of  the  TDMS.C  file 
to  produce  the  prototype  prograa. 

/****« 


line 

line 

line 

line 

line 

line 

line 

line 

line 


ude 

ude 

ude 

ude 

ude 

ude 

ude 

ude 

.ude 


'colors. h' 

'ctype.h' 

'dos.h' 

"error. h" 

‘filedata.h" 

"graphics. h" 

'intregs.h" 

"aath.h" 

'stdio.h" 


/***«*  6lol>al  Variables  »****/ 


{define  BACKGRHD  BLUE 
Idefine  FOREGRND  YELLOW 
•define  ERRCOLOR  YELLOW 
Idefine  FORTY  0 
Idefine  EIGHTY  2 
•define  HIGH  2 
Idefine  HEDIUH  1 
•define  TEXT  0 


/*  Background  co 
/*  Foreground  co 
/*  Foreground  co 


1 


/*  Code  for  forty  coluan  lode  */ 
/♦  Code  for  eighty  coluin  node  */ 
/*  High  res  code  »/ 

/*  Hediua  res  code  »/ 

/*  Text  aode  code  »/ 


iong  int  stack  :  40000; 
gvideoO; 


t  » 

*  MAIM  ♦ 

i  * 

Mtmmt«m**mmm*M***m*tmmmm*t*mM«**tmmtm***/ 


■ain() 

1 


int  key,  i,  J.k; 
char  storegrdlS], 

gridstrlSl,  *eapstorell?0 
FILE  *outule, 


k; 

neighbor! 
pstorefl/1 
♦afiie,  *bfi 


[5],  gridfle[8][10],  aapdataflO], 
e,  *cfile,  »dfile,«fopenO; 


ini tgraf (0,0,0) : 

dearkbdt): 

clrscrnO; 

page  ( ‘SETMAP.MMU* ) ; 


/*  Clear  keyboard  buffer.  */ 

/*  Clear  screen  */ 

/»  Display  the  getaap  Henu  screen.  */ 
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I /  3  *  ‘  • 


curlocat  (23,  30): 
aenuloop:  tiaeloopO; 
ecokey  (&kev): 
ten  (key) 

< 

case  T  :  clrscrnO; 

page  CGETGRID.HNU*); 
cur locat  (  23,  30): 
getestr  U.0,0, 1 ,2.*gr  idstr  ,0) ; 

strcpy(aapdata,  T); 
strcat(aapdata,*gridstr): 
strcat(napdata,'.DAT‘): 
if  (fiiexist(taapdata)-  0) 


/»  Hove  cursor  to  location  (23,31).  »/ 
/*  Display  an  active  date  and  tiae.  */ 

/*  CASE  OF  OLD  HAP  */ 

/*  GET  INPUT  */ 

I*  CREATE  HAP  FILENAME  */ 

/*  CHECK  IF  IT  EXISTS  */ 


c  Iscolor  ( FOREGRND ,  BACItGRND ) : 
cur  locate  9,  21): 

colrprts('*****Cannot  find  old  file  ‘,F0RE6RND,BACK6RND); 

curlocat(  11,  30): 

pause!); 

page  ('GETHAP.HNU'); 

curlocat  (23,  30): 

) 


else 

{ 

c Iscolor (FOREGRND. BACKGRND) : 
prntaap! Aaapdata) ; 
page  (  GETHAP.HNU*): 

curlocat  (23,  30); 

) 

goto  aenuloop; 

case  ’2’  :  clrscrnO: 

page('GETGRID.HNU'): 

curlocat  (23,  29); 
break: 

case  ’3’  :  guitO; 
clrscrnO: 

page  ('GETHAP.HNU'); 
curlocat  (23,  30): 
goto  aenuloop; 

default  :  error (); 
clrscrnO; 

page  ('GETHAP.HNU'); 

curlocat  (23,  30); 
goto  aenuloop; 


/♦  CASE  OF  HEN  HAP  */ 

/♦  QUIT  CASE  */ 

/*  RESULT  Of  NO  ANSNER  TO  QUIT  »/ 
/»  DAD  INPUT  ♦/ 

/♦  RESULT  OF  NO  ANSNER  TO  QUIT  */ 


iiiiiMinMtiiiiitiimiiiiiiiumtmmummmmmm/ 


it 

/* 

/* 

/» 

/* 

/» 

/* 


THIS  SECTION  DETERHINES  THE  NEIGHMRING  DATA  FILES 
RASED  ON  THE  USER  INPUT  OF  THE  LONER  LEFT  HAND  GRID. 

NEIGHBORS  A/M  1/001  C/+201  D/+301 

E  F/MOO  G/4200  H/»300 


yiiMMiiiiitMMiiiiimmitmmmmmimttmmmim/ 


getcstr(A,0,0,l,2,»gridstr,0): 
strcpy(store«rd,  *gridstr): 
strcpy(neighbor(«),  •gridstrl; 


/*  load  neighbor  E  »/ 


for ( i :  5;  i<:  7;  Hi) 

If  (storegrd[lj  "  ’9’) 


storegrddl  'O’; 
if  (storegrd(O)  "  '9') 
storegrd{0]  ’O’; 
else 

storegrd[Q)  -•  storegrd[0]  ♦  1; 


/*  LOAD  NEIGHBORS  F,  S,  H  */ 
/*  Bf  ADDING  100s  */ 


else 

storeardfl]  •-  storegrddl  ♦  1; 
|trcpy(  neighbor [i],  storegrd): 

strcpy (storegrd,  *gridstr>; 
if  (storegrd[3]  "  ’9’) 

storegrd[3]  =  ’O’; 
if  lstoregrd{2]  "  ’9’) 
storeqrd[2J  =  ’O’; 
else 

^storegrd(2]  :  storegrd[2]  ♦  1; 
else 

storeord(3j  =  storegrd[3]  ♦  1; 
strcpy (  neighbor [0] ,  storegrd); 

ford:  1;  i<:  3;  Hi) 

if  (storegrddl  "  ’9’) 

fMji.i0:; 

storegrdfol  =  ’O’; 
else 

^storegrd[0]  :  storegrd[0l  ♦  1; 
else 

storeardfl J  :  storegrddl  ♦  1; 
strcpy!  neighbor [ i j ,  storegrd): 


I*  RESET  BUFFER  */ 

/*  LOAD  NEIGHBOR  A  */ 
/*  BY  ADDING  i  */ 


/*  LOAD  NEIGHBORS  B,  C,  D  */ 
/*  BY  ADDING  100$  */ 


/♦  THIS  SECTION  CREATES  THE  DATA  FILE  HANES  ANO  THE  »/ 
/*  COHPOSITE  FILE  NAHE.  */ 
/*  »/ 
. . . . . 


(  1  :  0:  i<:  7;  Hi) 


for 
{ 

strcpy (gr idf 
strcatlgndf 
|trcat(gridf 


Ineigiiorlil); 

«  .  MT  ) , 


/*  CREATE  NEIGHBOR  DATA  FILENAMES  */ 
/*  end  of  for  */ 


c lscolor ( FOREGRND .BACKGRND) ; 
curlocati  10,  21); 

colrprtsl*  STANDBY  PLEASE*, FOREGRND, BACI6RND); 
curlocati  11,  30); 


t 


str 

str 


iillW't*’ 


li4P<lttl,0. 1 1 10) ; 


/*  CREATE  COHPOSITE  HAP  FILENAME  »/ 


jmttmmmmmmmmumtmmmmmmmmtmi 
/*  THIS  SECTION  OPENS  THE  OUTPUT  AND  DATA  FILES.  THEN  IT  */ 
/*  READS  FROH  THE  DATA  FILES  AND  NRITES  TO  THE  COHPOSITE  »/ 
/*  FILE.  A  THROUGH  D  ARE  READ  FIRST  AS  A  GROUP  FROH  TOP  */ 
/*  TO  BUTTON,  RON  BY  RON,  THEN  E  THROUGH  F.  */ 
/*  A  B  C  D  :>  COHPOSITE  */ 
/*  E  F  G  H  ♦/ 
/*  * 


outfile  -  fopenliapdata,  "a”); 


/*  OPEN  OUTPUT  FILE  */ 


for  (  k  :  0;  k<:  1;  Hk) 


/*  DO  FILES  0-3  THEN  «  -  7  */ 


/»  THE  USE  OF  SUBSTITUTE  DUHHY  FILES  NILL  BE  USED  IN  FUTURE  UPDATES*/ 
/♦  TO  FILL  IN  NHL RE  DATA  IS  NOT  AVAILABLE  */ 


if  lfile»ist(Kgridfle[0+j])"  0) 


/*  OPEN  NEIGHBORS  */ 

/*  CHECK  IF  IT  EXISTS  */ 


dscolor  (FOREGRND.BACXGRND); 
cur  locate  9,  211; 

colrprts  ■*******«****DATA  NOT  AVAILABLE  ’.FOREGRND.BACXGRND); 

curlocat!  11,  30); 
pause! ) ; 

page  rGETHAP.HNU’): 

curlocat  (23,  30); 

|oto  uenuloop; 


/«  OPEN  DATA  FILE  */ 

I*  CHECK  IF  IT  EXISTS  */ 


flscolor (FOREGRND.BACXGRND); 
curlocat!  9,  21); 

colrprtsC********M**DATA  NOT  AVAILABLE  ’.FOREGRND.BACXGRND); 

curlocatt  11,  30); 

paused: 

page  (  &THAP.HNU’); 
curlocat  (23,  30): 
goto  aenuloop; 


Ofile  ;  topen(gndfle[ldl,  V); 
if  (fileiistUgridfle[2*jj)"  0) 


/»  OPEN  DATA  FILE  */ 

/*  CHECK  IF  IT  EXISTS  »/ 


dscolor  (FOREGRND.BACXGRND); 
curlocat!  9,  21); 

colrprts) •*«**********DATA  NOT  AVAILABLE  ’.FOREGRNO.BACIGRND); 

curlocat!  11,  30); 

pause( ); 

page  rGETHAP.HNU’): 

curlocat  (23,  30); 
goto  MfiulooP: 


Cf lie  ;  fopet)(gridflel2*i|,  V);  /*  OPEN  DATA  FILE  «/ 
if  (fileust(4gridflefj*j|)::  01  I*  CHECK  IF  IT  EXISTS 


1 

c lscolor ( FOREGRND ,BACK6RND ) ; 
curlocatt  9,  21): 

colrprts('************DATA  NOT  AVAILABLE  “, FOREGRND, BACKGRND); 
curlocat!  11,  30); 
pause* ): 

page  rGETNAP.MNU*): 

curlocat  (23,  30): 
goto  perm  loop: 


dfile  :  fopen!gridflef3+j],  V):  /*  OPEN  DATA  FILE  */ 

for  U  :  1;  i<:20;  Hi)  /*  COPY  DATA  FILES  COMPOSITE  NAP  FILE  */ 


tscanf(af ile, *X160s* .papstore) ; 
fprintf(outfile,*X160s\  papstore): 
fscanf (bf ile, “Xl60s‘ ,«apstore) : 
fprintfloutf lie, 'Xl60s*.  papstore); 
fscanf (cfi le,*X160s- .papstore) ; 
fpr intf (outf iie,*il60s" ,  papstore): 
fscanftdf ile, ‘X160s*, papstore): 
fprintf(outfile,'Xl60s\n*,  papstore): 


fc 
fc 
fc 
fc 

I  I*  END  READ\HRITE  FOR  «/ 


.osetafile) 
ose(bfile) 
.ose(cfile) 
oseldf ile) 


fdose(outfile): 
c lscolor (FOREGRND, BACIGRNDt : 


prntpap(ipapdata): 
page  rGETHAP.HHU1) 
curlocat  (23,  30); 
goto  penuloop: 


/*  COMPOSITE  FILE  COMPLETE.  DONE  UITH  NEIGHBORS  */ 


) 

/iimMiiMMMiiHMMmtmMittiMMMiiiMKtimmMHMmnmn*/ 

/♦  »/ 

/*  SOB-SYSTEM  MODULES  */ 

/»  »/ 


. . . 

/•  PRNTNAP  */ 

.*  Given  an  0  grid  aap  file  this  procedure  produces  a  pap  on  the  screen  */ 

?rnteap(papdata) 

:l,ir  Us.pijtJ: 


int  elevcolr,  descolr,  roes,  linecnt,  gridcnt,  i, 
dev.  scalebase,  roestart,  roechng,  eater; 
char  design,  eapsortM,  streievf4] ; 

FILE  ‘indie,  *fopen(): 


initgrafiO.O.Oi; 

clearkbdd: 

drscrnO: 


I*  Clear  keyboard  buffer.  *1 
/*  Clear  screen  */ 


infile  =  fopen(aapdata,  V); 

c Iscolor (FOREGRND ,8ACKGRND) ; 

curlocat(0,0); 

elevcolr  :  GREEN: 

desroir  :  BLACK; 

rows  :  1; 

oridcnt  :  1: 

Iinecnt  :  1; 
rowchng  :  0: 

for  ( i - 1 ;  i!:1^20:  Hi) 

fscanf(  infile,  "X3s\&strelev); 
fscanf  Unf  ile,  *I5s"  .aapsort): 
if  (.1  ”  1  ) 


t 

sscanftstrelev.'td”,  Jscalebase); 
rowstar scaiebase: 

) 


if  (  rowchng  )  0  ) 
while  (  rowchng  )  0) 


{ 

--scaiebase: 
if  (elevcolr  >=  CYAN 
--elevcolr: 
else 

elevcolr  :  WHITE: 
--rowchng; 


else  if  (  rowchng  (  0) 
while  (  rowchng  <  0) 

♦♦scaiebase: 
if  (elevcolr  {■-  BROWN  ) 
♦♦elevcolr: 
else 

elevcolr  :  GREEN; 
♦♦rowchng; 


sscanf (strelev, *td" ,  ielev); 
if  (  elev  )  scaiebase  ) 
while  (  elev  )  scaiebase) 


I*  INITIALIZE  COLORS  */ 

/*  INITIALIZE  ROW  COUNT  */ 

/*  INITIALIZE  GRID  COUNT  »/ 

/*  INITIALIZE  LINE  COUNT  */ 

/*  INITIALIZE  RON  CHANGE  COUNT  */ 


I*  DETERMINE  COLOR  */ 


!*  SAVE  VALUE  OF  1st  ROW  ELEV  */ 


/*  NEW  ROW  ADJUST  FOR  COLOR  i  SCALE  */ 


I*  CHANGE  COLORS  */ 


/*  CHANGE  COLOR  */ 


/»  IS  ELEV  HIGHER  ?  ♦/ 

I*  INCREMENT  SCALE  TO  HIGHER  ELEV  »/ 


1 

♦♦scaiebase; 
if  (elevcolr  {-  BROWN  ) 
♦♦elevcolr: 
else 

elevcolr  :  GREEN; 


else  if  (  elev  <  scaiebase  ) 
while  (  elev  <  scaiebase  ) 


/*  CHANGE  COLOR  */ 


I*  IS  ELEVATION  LOWER  ?  */ 
/♦  DECREMENT  SCALE  */ 


l 

--  scaiebase: 

if  (elevcolr  >:  CYAN  )  /*  CHANGE  COLORS  «/ 

-elevcolr; 
else 

elevcolr  :  WHITE: 


/«  END  CHECK  FOR  ELEVATION  COLOR  CHAN6E  »/ 


switch  (aapsort(li) 

{ 

case  ’0’  : 

switch  (  aapsort[2]  ) 

{ 

case  ’O’  : 

case  ’C  : 

desian  -  ’ 
break; 

case  ’2’  :  water  -  BLUE: 
design  =  ' 
break; 

case  ’F’  :  design  ; 
break; 

case  ’S’  :  design  :  ,v’; 
break: 

case  ’B’  :  design  : 
break: 

case  ’U’  :  design  :  T; 
break; 

case  'O’  :  design  :  'o’; 
break; 

case  T  :  design  :  ’t'; 
break; 

case  ’1’  :  design  =  T; 
break; 

case  ’3’  :  design  :  ’1’; 
water  :  BLUE; 
break: 

case  V  :  design  - 
break; 

default  : 

desian  :  ’  ’; 
break; 

1 

break; 

case  ’B’  :  design  =  ’B ’ : 
break; 

case  ’G’  ;  design  =  'b': 
break; 

case  :  design  -- 
break; 

case  ’N’  :  design  : 
break; 

case  ’D’  :  design  :  v; 
break; 

case  ’H’  :  design  =  ’  ’; 
break; 


I*  VEGETATION  SORT  ♦/ 

/*  CLEARING  OR  NO  DATA,  NO  CHANGE  */ 

/*  HATER  ,  BLUE  */ 

I*  FOREST  » I 

i*  SWAMP  OR  NET  RICE  */ 

/*  BRUSH  «/ 

/*  BUILT  UP  AREA  */ 

I*  ORCHARD  */ 

/*  TERRACED  */ 

/*  DRY  STREAMED  */ 

/*  STREAM  CHANNEL  * / 

/»  OFF  ROUTE  FORD  */ 

/*  TREAT  AS  NO  DATA  */ 

/*  END  OF  NO  DATA /  VEG  SNITCH  */ 

/*  ROAD  BRIDGE  */ 

/*  RAIL  BRIDGE  */ 

/<  ROAD  TUNNEL  */ 

/*  RAIL  TUNNEL  */ 

/*  DIVIDED,  DUAL  LANE  */ 

/*  HIGHWAY  */ 
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case  ’fi’  :  design  = 
break; 

/*  RAILROAD  *1 

case  ’A’  :  design  :  '8': 
break; 

1*  AIRFIELD  */ 

case  ’W’  :  design  -  T; 
water  -■  BLUE; 
break; 

/*  WATERWAY  */ 

case  V  ;  design  :  ’L ’ ; 
water  :  BLUE; 
break; 

/*  LOCK  */ 

case  ’F’  ;  design  -  ’F’; 
water  :  BLUE: 
break: 

/*  FERRY  SITE  ♦/ 

case  ’S’  :  design  :  T; 
water  :  BLUE: 
break; 

/*  FORD  SITE  */ 

case  ’E ’  :  design  :  ’?’; 
break; 

/*  ELECTRIC  LINES  */ 

case  ’C’  :  design  : 
break; 

/*  ROAD  (ALL  WEATHER)*/ 

case  V  :  design  =  '  ’; 
break; 

/*  ROAD  (DRY)  */ 

case  T  :  design 
break; 

/*  CART  TRAIL  */ 

case  'V  :  design  = 
break: 
default  : 

switch  (  ■apsort(2]  ) 

/*  TRAIL  */ 

/*  TREAT  AS  NO  DATA  */ 

/*  VEGETATION  SORT  */ 

case  'O’  : 

/*  CLEARING  OR  NO  DATA,  NO  CHANGE 

case  ’C’  : 

desian  :  ’  ’; 
break; 

case  ’2’  :  water  =  BLUE; 
design  =  ’ 
break; 

/*  WATER  ,  BLUE  ♦/ 

case  ’F’  :  design  = 
break; 

' A  * . 

/*  FOREST  */ 

case  ’S'  :  design  = 
break; 

« 

/*  SWAHP  OR  WET  RICE  */ 

case  ’B ’  :  design  = 
break; 

V; 

/*  BRUSH  */ 

case  ’u’  :  design  = 
break; 

T; 

/*  BUILT  UP  AREA  */ 

case  'O’  :  design  : 
break; 

'o’; 

/*  ORCHARD  */ 

case  T  :  design  = 
break; 

’t’; 

/*  TERRACED  »/ 

*/ 
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case  T  :  design  ;  T; 
break; 


/»  DRY  STREAH6ED  */ 


case  '3'  :  design  =  ’1’; 
water  ;  BLUE; 
break: 

case  V  :  design  =  T: 
Mater  :  BLUE: 
break; 

default  : 

design  :  ’ 
break; 


/*  STREAM  CHANNEL  */ 

I*  OFF  ROUTE  FORD  */ 

/»  TREAT  AS  NO  DATA  */ 

/*  END  Of  NO  DATA/VEG  SNITCH  »/ 


break; 

t 


if  (TOMS  ::  20) 
{ 


roMsd: 

if  (design  "  ’ 
design  :  ’!’; 
if  (gridcnt"4) 


I*  END  OF  TRANSPORTATION  SNITCH  */ 
I*  DETERMINE  VERTICAL  GRID  LINES  »/ 

/*  END  OF  LINE  ?  ♦/ 


{ 

gridcnt  :  1; 

roMchng  =  scalebase  -  roMStart; 
♦♦linecnt; 

) 

else 

^♦♦gridcnt; 


else 

HroMs; 

if  (linecnt  "  20) 

if  (design  "  ’  ’) 
^  design  : 


if( 

{ 


Mater  "  BLUE) 


colrprta(design,descolr,  Mater); 
Mater  :  BLACK: 


else 

^colrprta  (design,  descolr,  elevcolr); 


/♦  DETERMINE  CHANGE  FROM  START  */ 


/»  BOTTOM  OF  GRIDS  ?  */ 


/»  END  CREATING  PIC  FOR  LOOP*/ 


fdose(infile): 

'ausel); 

/*  END  OF  NODULE  */ 


/tmmmmmtmmmmmtmtmmmmmmmmmmm**/ 

SYSTEM  UTILITIES 

/«  */ 


'!*  *! 

/«  PAUSE  */ 

/*  */ 

/mmmttmmmmmmmmmtmmttmmmmmttmmtt/ 

paused 


dearkbdO: 
for  (  :  ;  I 


!*  Local  Boolean  variable.  »/ 

I*  Clear  keyboard  buffer.  */ 

/*  Starts  an  infinite  loop.  */ 


if((i  =  checkkeyO)  "  1)  break;  /♦  Poll  keyboard  for  an  input.  »/ 


clearkbdO; 

clscolor  (FOREGRND,  6ACKGRND): 


/*  Clear  keyboard  buffer.  */ 

I*  Clear  screen  and  set  colors.  */ 


/mmmmmmmmmmmmmmmtmmmmmtmmmm 
i  * 

*  PAGE  * 

*  v 

/mu 

Page  writes  a  screen  of  text  (ASCII)  to  the  screen. 

PARAMETERS: 

page. file  —  nawe  of  text  file 
CONTROL  CODES: 

.cn-  Center  the  next  n  lines. 

.e  -  Echo  the  output  to  the  printer  if  the  user  requests  it. 

.a  -  Display  the  centered  aessage:  "Press  any  key  to  continue  or  Q 
to  quit*  on  line  24.  Pressing  a  key  causes  screen  erasure. 

.p  -  Pause.  Pressing  a  key  causes  screen  erasure. 

.4  -  Forty  coluan  aode  (erases  screen). 

.8  -  Eighty  coluan  aode  (erases  screen). 


page  (page  file) 
char  *page_file: 


/*  Set  pointer.  */ 


int  cent,  col,  i,  aode,  pf lag,  plines,  row;  /»  Local  integer  variables.  */ 

char  *f lag-  /»  Set  pointer.  »/ 

char  1 ine[80] :  /»  Open  character  array  of  80.  »/ 

FILE  *inf lie,  *fopen();  /»  Set  pointers.  *1 

pflag  :  0;  /*  Initialize  pf lag  value.  */ 

/♦»»»**  open  the  page  file  *»»»»/ 

if  ((infile  -  fopen  (page.file,  "r"))  ==  NULL) 

clscolor  (FOREGRND,  BACKGRND);  /♦  Clear  screen  and  set  colors.  ♦/ 
curlocat(  9,  0);  /*  Start  writing  with  cursor  at  (9,0).  »/ 

colrprts  ***********  page  cannot  open  text  file.  **********  *  ,  FOREGRND,  6ACK6RND); 
curlocat  11,  10):  /*  Start  writing  with  cursor  at  (11,10).  */ 

colrprts  page  file,  FOREGRND,  BACKGRND):  /»  Clear  screen  and  set  colors.  */ 
curlocat  24,  30):  /»  Start  writing  with  cursor  at  (23,33).  */ 

return: 


!*****  Begin  reading  in  text.  *****/ 

row  -  0;  /♦  initialize  row  value.  *1 

c£ni  :/9i.  £  *  ,,  /*  Initialize  cent  value.  */ 

while  ((flag  =  fgets  (line,  80,  infile))  \-  NULL) 

if  (linefo]  "  '.’)  /*  If  1st  line  array  value  :  .  then  ...  »/ 


/**♦**  Interpret  the  coaaand.  ♦****/ 
switch  (line(il) 


I*  Set  up  conand  code  variable  array.  */ 


/***♦*  .c  n  -  Center  the  next  n  lines.  ttttt/ 


V  V 

cent  :  atoi  (&line[2] ) : 
break; 


I*  Break  out  of  the  loop.  */ 


/♦****  .e  -  Echo  the  output  to  the  printer.  »****/ 
case  V: 

clscolor  (FOREGRND,  BACXGRND);  ft  Clear  screen  and  set  colors.  *f 
curlocat  12,  23);  /»  Start  writing  with  cursor  at  (12,  23).  */ 

colrprts  (  Do  you  want  printed  output  (Y/N)?",  FOREGRND.BACKGRND); 

|t  (getyesno(l))  ft  Get  Boolean  value  of  Y/N  input.  */ 

pfiag. =  1;.  .  I*  Set  of lag  value.  ♦/ 

^  for  (1=1;  1  <:  6;  m)  IprtlfO:  /*  Print  line  for  i  1  to  6  X.  */ 

clscolor  (FOREGRND,  BACXGRND);  /*  Clear  screen  and  set  colors.  */ 
plines  :  0;  /t  Initialize  value.  */ 

break;  (t  Break  oat  of  the  loop.  */ 


l*tttt  .■ 


Display  the  centered  aessage;  "Press  any  key  to  continue  or  Q  to  quit" 
on  line  24.  Pressing  a  key  causes  screen  erasure,  ttttt/ 


getscaod  diode,  &i,  &i ) - 
if  (aode  ( -  1)  curlocat  (24, 

else  curlocat  (24,  21) : 
colrprts  (“  Press  any  key  to 
getkeydi): 

if  (d  "  V)  !!  (i  ==  ’Q’)) 


fdose  (infile); 
ir  ( pf lag) 

IprtffO; 

return; 

1 

clscolor  (FOREGRND,  BACK6RND) 

row  -  0; 

break: 


It  Get  screen  display  aode  integer  value.  »/ 
2):  / t  If  Boolean  false,  start  writing  */ 

/*  at  curcor  location  (24,  2).  */ 

It  start  writing  with  cursor  at  (24,  21).  »/ 
continue  or  Q  to  quit",  FOREGRND,  8ACK6RND); 

It  Nait  for  key  pressed.  */ 

It  If  key  pressed.  */ 

I*  If  pflag  set.  */ 

I*  Print  infile.  */ 

;  /*  Clear  screen  and  set  colors.  »/ 

/»  Initialize  row  value.  »/ 

I*  Break  out  of  the  loop.  */ 


/**♦**  .p  -  Pause,  ttttt/ 


case  ’p’: 


paused: 
row  :  0; 
break : 


I*  Nait.for  key  pressed.  »/ 
ft  Initialize  row  value.  */ 
/*  Break  out  of  the  loop.  */ 


/*»**»  .4  -  Forty  coluan  aode  (erases  screen).  »*♦»*/ 
case  ’4’: 

setscaod  (FORTY) :  /*  Set  screen  display  «ode  to  40  columns.  */ 

border  (6ACKGRN0) :  I*  Set  border  color.  »/ 

clscolor  (FOREGRND,  BACKGRND);  /*  Clear  screen  and  set  colors.  */ 

row  -  0;  /*  Initialize  row  value.  *] 

break:  /*  Break  out  of  the  loop.  ♦/ 


/*»***  a 


Eighty  coluan  aode  (erases  screen).  *****/ 


case  ’8’: 

setscaod  (EIGHTY) ;  /*  Set  screen  display  lode  to  80  coluans.  */ 

border  (BACKGRND) ;  /♦  Set  border  color.  »/ 

clscolor  (F0RE6RND,  BACKGRND);  /»  Clear  screen  and  set  colors.  ♦/ 

row  ;  0;  !*  Initialize  row  value.  »/ 

break;  /♦  Break  out  of  the  loop.  */ 


line  [strlen  (line)  -1]  :  ’\0’:  /*  Print  the  line.  */ 
if  (cent  >  0) 


/**»**  Process  centered  lines.  **»«/ 

getsceod  ((aode,  &i ,  4i);  /*  Deteraine  display  aode.  */ 

—cent:  I*  pecreaent  cent.  *1 

if  (aode  (-  1)  col  :  (40  -  strlen  (line))  12;  I*  Calculate  center  »/ 
,  I*  of  line  if  40  col.  aode.  »/ 

else  col  =  (30  *  strlen  (line))  / 2:  /»  Calculate  center  of  line  */ 

/*  if  80  col.  aode.  */ 


else  col  :  1; 
if  (row  > -  24) 

1 

row  :  0: 

) 

if  ( pf lag  44  (plines  >  54)) 

plines  =  0; 

IprtffO; 


/*  Set  col  :  1.  »/ 

/*  Initialize  row.  */ 

/*  If  pflag  set  and  nuaber  of  lines  >  54.  */ 

'*  Initialize  plines.  *1 
I*  Print  line.  »/ 

A  li.  T _ 1  •  '  f  .  _  «  _  v  x  I 


for  (i=l;  i  (:  6;  i++)  IprtlfO;  /*  Increaent  i  froa  1  to  6.  */ 


if  (pflag) 


I*  If  pflag  set.  */ 


if  (col  >  1)  for  ( i - i ;  i  (  col;  !♦♦)  Iprtchar (0,  ’  ')-, 
lprtstr  (line);  /♦  Print  string.  »/ 

IprtcrO; 

IprtlfO;  /»  Print  line.  »/ 

plines>+:  I*  Increaent  plines.  *1 


^  panes**: 
curlocat  (*+row,  col) 


Start  writing  with  cursor  at  (row.col).  */ 


uuiiuvav  uvif,  /T  v  mi  auiiy  mill  vui  avi  ai  \i  vw* 

colrprts  (line,  F0REGRND,  BACKGRND);  /»  Clear  screen  and  set  colors.  »/ 


fdose  (infile); 
if  (pflag) 
IprtffO; 
return; 


/*  Close  file  buffer.  »/ 
/»  If  pflag  set.  »/ 

/♦  Print  infile. 
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*  * 

*  TIHELOOP  * 

t  * 

/»**»* 

•iieioop  displays  the  systea  tiie  and  date  at  the  bottoi  of  the  «enu  title  board. 

PARAMETERS: 

None. 

*♦»*»/ 

tueloopO 


int  i,  1,  row.  col: 
char  dtliOj, 
ta  12  : 


clearkbdl);  /*  Clear  keyboard  buffer.  *1 

curgetUrow,  &col):  /»  Place  cursor  at  location  of  pointers  (row, col).  4/ 
for!  :  ;  )  /*  Start  infinite  loop.  */ 


I*  Local  integer  variables.  */ 
/*  Date  display  buffer.  ♦/ 

/♦  Ti«e  display  buffer.  */ 

/*  Clear  keyboard  buffer.  * / 
location  of  pointers  (row, col). 
I*  Start  infinite  loop.  */ 


curtype  (1,  0,  0): 

if((i  =  checkiey(l)  "  1)  break; 

systiwe  (4ta,  9); 

sysdate  (idt,  24): 

curlocat  (  8,18); 

coirprtsldt ,FOREGRNO,BACK GRND ) ; 

curlocaH  8,52); 

coirprts  (ta,  FdREGRNO ,  BACK6RND) ; 

curlocat(row.col): 

curtype(0,6,7); 

for  (i  :  1;  i  <r  1000;  i++) 


I*  Turn  cursor  off.  */ 

/*  Mait  for  key  pressed.  »/ 

/*  Load  the  systiae  buffer  in  the  #9  foraat.  */ 

/*  Load  the  sysdate  buffer  in  the  124  foraat.  */ 

I*  Start  writing  at  cursor  location  (8,12).  » / 

I*  Print  contents  of  the  sysdate  buffer  in  set  colors.  */ 
I*  Start  writing  at  cursor  location  (8,46).  */ 

I*  Print  contents  of  the  systiae  buffer  in  set  colors.  */ 
/*  Start  writing  at  cursor  location  (row, col).  */ 

/*  Turn  cursor  on  and  set  colors.  V 
/•  Increaent  i  fro*  1  to  1000.  */ 


if((j  -  checkkeyO)  "  1)  goto  done;  /♦  On  key  pressed  log  off  and  exit  to  DOS.  */ 


done:  curtype(0,6,7); 
return: 


/*  Turn  cursor  on  and  set  colors.  */ 


«  4 

*  ERROR  4 

*  t 

/****♦ 

The  error  routine  beeps  the  speaker  and  returns  the  cursor  to  the  sale  coluan,  previous  row. 
It  is  used  to  signal  bad  data  input. 

PARAMETERS: 

None. 

4**44/ 

error () 


int  row.  col: 
curoet  (trow,  (col): 
curlocat  (row,  col  - 
beepi); 


/»  Initialize  row.  col  integer  variables.  */ 

/ *  Set  location  of  cursor  at  pointers  row,  col.  4/ 
/ 4  Start  writing  at  cutsor  location  (9,2).  »/ 

/ 4  Sound  the  error  warning.  4/ 


return; 


} 

/omommmmmmmmmmmmmmmmmmmmm** 


t  * 

*  ERRMSG  * 

i  * 


litm 

rms  routine  prints  a  centered  error  lessage  on  lineno,  beeps  once  and  pauses. 
The  user  strikes  a  key,  the  lessage  is  cleared  and  control  is  returned. 


PARAMETERS: 

lineno  --  Location  of  the  cursor  and  the  error  lessage. 
isg  --  Error  lessage  to  be  printed. 

♦mi/ 

errisg  (lineno.  isg) 


int  lineno: 
char  *isg: 


/*  External  integer  variable.  */ 

I*  Pointer  to  external  character  variable.  ♦/ 


1 


1 


int  i,  lode;  /♦ 
getsciod  Uiode,  4i,  4i):  /» 
if  dode)  i  -  (80  -  strien  (isg))  /2:  /♦ 
else  i  ^  (40  -  strien  (isg)!  / 2;  /» 
curlocatUineno,  i):  /* 
colrprtsdsg,  ERRCOLOR , BACKGRNO) ;  /* 
beepO;  /* 
getkey  (4i);  /♦ 
curlocatUineno,  i);  /* 
colrprtst  ‘ 

F0RE6RHD , BACKGRND ) : 


Local  integer  variables.  */ 

Deteriine  screen  display  lode  and  set  colors. 
Calculate  center  of  string  in  80  coluan  lode. 
Calculate  center  of  string  in  40  coluw  tode. 
Start  anting  at  cutsor  location  (9,2).  »/ 
Print  in  set  colors.  »/ 

Sound  error  Naming.  */ 

Wait  for  key  pressed.  */ 

Start  anting  at  cutsor  location  (9,2).  */ 

/»  Print  in  set  colors.  »/ 


2 


/mtmmmmtmmtmmmmmmmmmmrnmmmmim 
»  ♦ 

*  QUIT  » 

*  t 

t*m»mmmmmmmmmmmmmmmmmmmmMmm/ 

/♦♦♦♦* 

uuit  causes  the  prograi  to  exit  to  DOS. 


PARAMETERS: 

None. 


int  i: 


/*  Local  integer  variables.  */ 


dscoior  (FORESRhO.  MCIGRND t : 
: learned! ) : 
page  Cotm.nnu'): 
cur  local  (2«,  30); 


/*  Clear  screen  and  set  colors.  */ 

/*  Clear  keyboard  buffer.  »/ 

/«  Display  the  Exit  hew.  */ 

/*  Set  cursor  at  location  (24,301.  */ 


i=  ecoyesno(2«,  30,  H; 
it  (i  "  1) 

1 

mitgraf  <0,  0,  0): 
e»ltl); 

1 

eise 

return; 


/*  Check  keyboard  for  a  Y/h  input  uith  echo.  »/ 

/*  Clear  screen.  * I 
/*  Exit  to  DOS.  »/ 

/*  Return  to  routine.  */ 


/«»»**m*i««m**«*m******M*mt*m***m*t*mMmmmmm**m 
*  » 


NOTYET 


/»**»» 

hotyet  is  a  duany  routine  to  hold  a  place  for  future  functions. 


PARAMETERS: 

hone. 


MENU: 


THIS  FURCTIOh  HOT  YET  INPIEHEMTED 


Press  a  key  to  continue. 

»****/ 


not yet  0 


int  1: 

c lscolor ( F  ORE  &RM0 , BACK  GRHO ) ; 
page  ( “HOTTET.HHO^I; 
curtype  (0,  0,  0); 
curlocat  (24,  1); 
getheyUi): 
curtype  *0,  0,  0); 
return: 


I 


Local  integer  variable.  »/ 

Clear  screen  and  set  colors.  */ 
Display  the  notyet  passage.  •/ 
turn  off  cursor.  */ 

Set  cursor  at  location  (24,1). 
bait  for  key  pressed.  •/ 

Turn  on  cursor.  * / 

Return  to  sysaain  routine.  • / 


•/ 
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